CockroachDB vs MySQL

Quick verdict

CockroachDB, from Cockroach Labs, is a distributed SQL database: data is split into ranges that are replicated, by default three times, with Raft consensus, and every node accepts SQL. It implements the PostgreSQL wire protocol and much of PostgreSQL's dialect; it does not implement the MySQL protocol or dialect. Current releases are v26.3 (Innovation) and v26.2 (Regular). Architecture, isolation, multi-region features and the 2024 licence change are covered in detail in CockroachDB vs PostgreSQL; this page focuses on what changes when the starting point is MySQL.

MySQL is Oracle's open source relational database. MySQL Community Server is licensed under GPLv2, with commercial editions (Standard, Enterprise and Cluster CGE) and the MySQL HeatWave cloud service. It uses calendar versioning: 26.7 is the current Innovation release, and 9.7 and 8.4 are the Long-Term Support lines. A standard MySQL deployment has one writable source with replicas; Oracle's own high-availability stack is Group Replication, packaged with MySQL Shell and MySQL Router as InnoDB Cluster.

Side by side

Key differences

Compatibility: PostgreSQL-flavoured, not MySQL-flavoured

A MySQL driver cannot connect to CockroachDB. Applications must switch to a PostgreSQL driver (or an ORM dialect for PostgreSQL or CockroachDB) and their SQL must be adapted. Cockroach Labs' MySQL migration guide lists the main schema and behaviour differences:

• AUTO_INCREMENT is not supported; convert it to a sequence, a UUID with gen_random_uuid(), or unique_rowid().
• TINYINT becomes INT2, and INT on CockroachDB is 64-bit.
• ENUM columns become standalone CockroachDB enum types.
• Geospatial types need manual conversion.
• MySQL's FIELD() function is replaced by array_position(), which returns NULL rather than 0 when nothing is found.
• String comparison is case-sensitive in CockroachDB, while the guide notes it is case-insensitive in MySQL (with default collations); identifiers are the other way round, so quote them to preserve case.

Upserts are a typical rewrite:

-- MySQL 8.4
INSERT INTO accounts (id, balance) VALUES (3, 7500.83) AS new
ON DUPLICATE KEY UPDATE balance = new.balance;

-- CockroachDB (UPSERT always uses the primary key as the arbiter)
UPSERT INTO accounts (id, balance) VALUES (3, 7500.83);

-- CockroachDB, conflict on a named unique column
INSERT INTO accounts (id, balance) VALUES (3, 7500.83)
ON CONFLICT (id) DO UPDATE SET balance = excluded.balance;

Stored procedures, functions and triggers written in MySQL's procedural language must be rewritten; CockroachDB's routines use PL/pgSQL, with row-level triggers only.

What a MySQL to CockroachDB migration involves (MOLT)

Cockroach Labs' Migrate Off Legacy Technology (MOLT) toolkit has four parts. The documentation lists MySQL 5.7 to 8.4 as supported sources for Fetch, Replicator and Verify:

• Schema Conversion Tool, on the Migrations page of the CockroachDB Cloud Console, converts a MySQL (or PostgreSQL, Oracle or SQL Server) schema and marks statements with no CockroachDB equivalent as [incompat] for you to remove or work around.
• MOLT Fetch performs the bulk data load.
• MOLT Replicator streams ongoing changes. For MySQL it requires GTID-based replication: gtid-mode=ON, enforce-gtid-consistency=ON, and binlog-row-metadata=full on MySQL 8.0 and later (binlog-row-image=full on 5.7), with binlogs retained for the whole migration. It must connect to the primary, not a replica, captures INSERT, UPDATE and DELETE but not TRUNCATE, and fails if DDL runs during replication.
• MOLT Verify compares table structure, column definitions and row data between source and target. It is documented as in preview, cannot compare geospatial types, and for MySQL compares a single database with CockroachDB's public schema.

The documented delta migration (load, then replicate, then cut over) has ten steps: prepare the source, prepare the target schema with explicit primary keys and without secondary indexes and constraints, load with Fetch, verify, restore indexes and constraints, start Replicator, stop application traffic, drain replication, verify again and cut over. The data move is tooling; rewriting queries, ORM configuration, stored routines and adding retry handling for SERIALIZABLE transactions is application work, and in our view it is usually the larger part.

MySQL's own high availability: Group Replication and InnoDB Cluster

MySQL Group Replication keeps a group of servers consistent with a built-in membership service and automatic failure detection. In the default single-primary mode, one member accepts writes and a new primary is elected automatically if it fails; multi-primary mode lets every member accept writes. A group can have at most nine members. In multi-primary mode, SERIALIZABLE transactions are refused by default and tables with cascading foreign keys are not supported. Group Replication does not redirect clients by itself.

InnoDB Cluster packages Group Replication with MySQL Shell (AdminAPI) and MySQL Router, which routes applications to the current primary after failover. It needs at least three instances. InnoDB ClusterSet links a primary cluster to replica clusters in other locations for disaster tolerance, and InnoDB ReplicaSet covers simpler setups without automatic failover. All of these keep one write primary at a time (in single-primary mode), so they add availability and read capacity, not write scale-out. CockroachDB's difference is that every range has its own Raft group, so writes spread across all nodes.

Scaling MySQL out: Vitess, PlanetScale and Aurora

Vitess is an Apache-2.0 licensed sharding layer for MySQL and a graduated Cloud Native Computing Foundation project. It routes queries across many MySQL shards, so applications keep a MySQL protocol and dialect. PlanetScale sells Vitess as a managed service (MySQL 8), with non-blocking schema changes through deploy requests; its compatibility page states it does not support stored routines, triggers, events or LOAD DATA INFILE, and supports foreign keys only on unsharded databases. See PlanetScale vs AWS RDS and Neon vs PlanetScale.

Amazon Aurora MySQL-Compatible Edition separates compute from a cluster volume that keeps a copy of the data in each of several Availability Zones. A cluster has one writer and up to 15 Aurora Replicas, with automatic failover to a replica. Aurora scales reads and storage, not writes; Aurora Global Database extends it across regions. See Amazon Aurora vs MySQL.

MySQL also has NDB Cluster, a separate distributed storage engine with automatic sharding; it uses different storage and requirements from InnoDB and is not supported by InnoDB Cluster. In our view, a MySQL team that needs write scale-out usually looks at Vitess first, because it keeps InnoDB and the MySQL dialect, and at CockroachDB when multi-region survival and data placement matter as much as scale.

Licensing and where you can run each

MySQL Community Server is GPLv2, free for any use, and is offered as a managed service by every major cloud (Amazon RDS and Aurora, Google Cloud SQL, Azure Database for MySQL, Oracle's MySQL HeatWave) and by PlanetScale. CockroachDB is distributed under the CockroachDB Software License: free (Enterprise Free, with telemetry) only for businesses under USD 10M annual revenue, and its managed service comes only from Cockroach Labs. The details are in CockroachDB vs PostgreSQL. We describe licence terms only; take your own legal advice.

Pricing and licensing

CockroachDB: self-hosted Enterprise Free costs nothing for businesses under USD 10M annual revenue; larger businesses need a paid Enterprise licence from Cockroach Labs' sales team. CockroachDB Cloud organisations created on or after 15 September 2026 use the Cockroach Continuum pricing model (Standard and Mission Critical plans, billed per vCPU-hour plus storage and data transfer), with no free tier and a 30-day trial with USD 400 of credit. The listed Standard rate and plan details are in CockroachDB vs PostgreSQL.

MySQL: Community Server is free under GPLv2. Commercial editions (Standard, Enterprise, Cluster CGE) are sold by Oracle by subscription; we have not quoted their prices. Managed MySQL is priced by each provider, usually by instance hours plus storage, I/O and backups; PlanetScale Vitess was listed from USD 39 per month (PS-10, AWS us-east-1) on its pricing page in October 2026.

A migration also has a one-off cost in engineering time for schema conversion, query rewrites and testing. Prices exclude tax and change often.

Pricing checked on the vendors' official pages on 7 October 2026. Prices change; confirm before buying.

Where each one leads

Limitations

When to choose each

When neither is right

• You want a distributed database but your team prefers full PostgreSQL compatibility: compare CockroachDB vs PostgreSQL and MySQL vs PostgreSQL.
• You are on AWS and mainly need fast failover and read scaling for MySQL: see Amazon Aurora vs MySQL and Amazon RDS vs Amazon Aurora.
• Your access pattern is key-value at very large scale rather than relational: see DynamoDB vs MySQL.
• The pressure is analytical queries rather than transactional writes: see ClickHouse vs MySQL.

Final recommendation

Frequently asked questions

Sources

• CockroachDB: Migration overview (MOLT tools and supported sources)
• CockroachDB: Delta migration from MySQL
• CockroachDB: MOLT Replicator
• CockroachDB: MOLT Verify
• CockroachDB Cloud: Schema Conversion Tool
• CockroachDB: UPSERT
• MySQL 8.4 Reference Manual: Group Replication
• MySQL 8.4 Reference Manual: Group Replication limitations
• MySQL 8.4 Reference Manual: InnoDB transaction isolation levels
• MySQL Shell: InnoDB Cluster
• MySQL products and editions
• Vitess
• Vitess GitHub repository (licence)
• PlanetScale docs: MySQL compatibility (Vitess)
• Amazon Aurora DB clusters

Checked October 2026.

How we research comparisons: our editorial method.