What actually changes about your day when you move from one distributed SQL database to another? Not the benchmark numbers. Not the marketing slides. The workflow: how you retry a failed transaction, how you add a region, how you deploy a schema change at 2 p.m. on a Tuesday without waking anyone up. Those are the differences that decide whether a migration feels smooth or turns into a six-month slog.
Aurora DSQL, CockroachDB, and Google Cloud Spanner all promise globally distributed, strongly consistent SQL. Underneath, they ask engineers to work in genuinely different ways. This comparison focuses on those workflow differences, with a clear caveat up front: any claim about 2027 is a projection. The products are moving fast, and the details below reflect documented behavior rather than future roadmaps.
Why the workflow matters more than the feature list
All three systems speak a PostgreSQL-adjacent dialect. All three claim strong consistency. On a comparison chart, they start to blur. In daily practice, they diverge in three places:
- How conflicts are detected and who retries them
- How region topology gets configured, and whether that lives in SQL or in a control plane
- How schema changes behave while traffic is flowing
These are the areas where teams burn the most time. A database that retries silently and one that throws a serialization error back at your application feel completely different to the person on call at 3 a.m. If you are weighing broader platform choices alongside this decision, the same workflow-first lens applies to the Aurora DSQL vs CockroachDB vs Spanner 2026 comparison, which tracks how these trade-offs have shifted year over year.
Concurrency control: optimistic, lock-based, or both
This is the single biggest workflow difference, and it shapes application code more than any other factor.
Aurora DSQL leans optimistic
Aurora DSQL was announced at AWS re:Invent in December 2024 as a preview. Its documented consistency model is strong consistency built on optimistic concurrency control (OCC) rather than lock-based pessimistic transactions. In plain terms: the database lets transactions run without grabbing locks, then checks for conflicts at commit time. If two transactions collided, one has to retry.
That design is elegant under low contention and brutal under high contention if your application is not built for it. The practical consequence is that retry logic is not an afterthought in DSQL. It is part of the contract. Engineers who treat it as an afterthought end up with mysterious failed writes under load.
CockroachDB uses serializable isolation with lock-based transactions
CockroachDB defaults to serializable isolation and handles contention through locking plus transaction push and abort mechanics. When a serialization conflict occurs, the client receives a retry error. CockroachDB’s documentation describes client-side retry loops for these serialization errors, commonly referenced by the 40001 error code.
Anyone who has written application code against PostgreSQL will recognize the pattern, because serialization failures are a standard part of the isolation-level landscape. The PostgreSQL documentation on transaction isolation explains why serialization failures happen and why well-behaved applications must be prepared to retry. CockroachDB’s workflow simply makes that requirement unavoidable rather than occasional.
Spanner is pessimistic by default, optimistic on request
Spanner’s default concurrency is pessimistic locking, with an optional optimistic mode for read-write transactions. That means the default experience is closer to a traditional relational database: transactions wait rather than fail. The trade-off is latency under contention, not retry storms.
| Database | Default concurrency | What the app must handle |
|---|---|---|
| Aurora DSQL | Optimistic (OCC) | Explicit conflict handling and retries |
| CockroachDB | Lock-based, serializable | Client-side retry loops on serialization errors |
| Spanner | Pessimistic locking | Waiting under contention; optimistic mode optional |
The workflow lesson: if your codebase has never handled retries, Spanner’s default will feel most familiar. If your team already writes retry-aware code, DSQL and CockroachDB will not surprise you. If your team has never thought about it, budget real engineering time before you migrate.
Configuring regions: SQL statements versus control planes
Multi-region setup is where the three products reveal their philosophies most clearly.
CockroachDB treats region topology as a schema concern. You configure it through SQL statements such as setting a primary region, adding regions, and choosing table locality patterns like regional-by-row. Multi-region SQL reached general availability in CockroachDB v21.1 in 2021 and has been documented since. The workflow implication is significant: region placement lives in migrations, gets reviewed in pull requests, and can be version-controlled alongside your schema.
Spanner manages multi-region configuration through instance configuration and database creation options, not per-row SQL locality clauses. The placement decision happens at a different layer, closer to infrastructure provisioning. That separation can be cleaner for platform teams and more awkward for application developers who want to reason about data locality in the same place they reason about tables.
Aurora DSQL’s preview documentation described an active-active multi-Region write model. As with any preview-era detail, verify the current behavior before you design around it.
The practical tip here: whichever system you choose, write down where region topology lives before you start. Teams that skip this step discover during an incident that nobody remembers which layer controls placement.
Online schema changes sound like a checkbox feature. In practice, they determine whether you can ship database changes during business hours.
CockroachDB performs online schema changes by default, which means adding a column or an index does not require a maintenance window in the typical case. Spanner historically required DDL with more limited online-change semantics, though this has improved over time. Aurora DSQL’s preview documentation described DDL limitations, and what those look like in 2027 is genuinely unknown.
A realistic workflow habit for any of the three: test schema changes against production-sized data in a staging environment before trusting the online-change claim. Vendor documentation describes behavior; your workload decides whether that behavior holds.
Compatibility claims deserve skepticism
All three products advertise PostgreSQL compatibility, and the depth varies considerably. CockroachDB and Aurora DSQL both target PostgreSQL wire and dialect compatibility. Spanner offers a PostgreSQL-dialect interface, with GoogleSQL as its default, and that interface reached general availability in 2023.
The word “compatible” is vendor-defined and not equivalent across products. A driver that connects is not the same as an ORM that behaves, and an ORM that behaves is not the same as a stored procedure that ports cleanly. Treat every compatibility claim as vendor-sourced until your own test suite confirms it. This is the same discipline that pays off when comparing local-first tools, as covered in this breakdown of Obsidian vs Logseq local-first notes compared by workflow — the workflow fit matters more than the feature checklist.
Consistency models in plain terms
Spanner offers strong external consistency, effectively linearizability on a global scale, and it achieves this using TrueTime. The original paper, “Spanner: Google’s Globally-Distributed Database,” published at OSDI 2012, describes TrueTime and the external consistency guarantee in detail. It remains the clearest explanation of why Spanner’s model is unusual.
Aurora DSQL and CockroachDB both claim strong consistency too, but they get there through different mechanisms, and the mechanisms leak into the workflow. Spanner’s approach hides timing complexity inside the infrastructure. DSQL’s optimistic model pushes conflict handling into your application. CockroachDB’s serializable model pushes retries into your client code. None of these is wrong. They simply distribute the work differently.
A practical migration checklist
Before committing to any of the three, run through these steps:
- Audit your application for retry logic. If it has none, note that DSQL and CockroachDB will require adding it.
- Map where region topology would live in your stack. Decide whether SQL-based configuration or control-plane configuration fits your team’s habits.
- Test schema changes against realistic data volumes and measure the impact on live queries.
- Run your actual ORM and driver test suite against each candidate. Do not trust compatibility claims without evidence.
- Simulate contention. Run a load test with hot rows and watch how each system behaves and what errors surface.
- Document the retry semantics your application expects, so future engineers inherit the knowledge.
The most common mistake is treating these databases as interchangeable because they all speak SQL. The second most common mistake is picking based on benchmark throughput when the real cost shows up in application code. A team that already writes careful retry logic will find DSQL and CockroachDB comfortable. A team that wants the database to absorb contention will prefer Spanner’s defaults.
How to think about the 2027 question
No published 2027 roadmap existed for any of these products at the time this comparison was assembled. Aurora DSQL was still in preview as of December 2024, and its general availability timing and final feature set were not public. That means any 2027-specific workflow claim should be treated as projection, not fact.
The honest approach: build your evaluation around documented behavior today, then re-verify against current documentation before you sign anything. The workflow differences described here are structural. Optimistic versus pessimistic concurrency is not a bug that gets patched away. Region configuration living in SQL versus a control plane is an architectural choice. Those fundamentals are likely to persist even as features evolve.
Conclusion
Aurora DSQL, CockroachDB, and Spanner all deliver distributed SQL with strong consistency, and all three will run your workload. The differences that decide whether you enjoy the experience are workflow differences: who retries, where region topology lives, and how schema changes behave under traffic. DSQL asks your application to handle conflicts. CockroachDB asks your client code to retry serialization failures. Spanner asks your transactions to wait. Pick the one whose demands match your team’s existing habits, test it against real contention, and verify every claim against current documentation rather than a comparison chart. That discipline will serve you better than any benchmark, in 2027 and beyond.
FAQ
What is Aurora DSQL?
Aurora DSQL is a serverless, distributed SQL database from AWS, announced at re:Invent in December 2024 as a preview. It offers active-active multi-Region writes, a PostgreSQL-compatible query surface, and strong consistency built on optimistic concurrency control.
Does CockroachDB require retry logic in application code?
Yes, in practice. CockroachDB uses serializable isolation with lock-based transactions, and serialization conflicts surface as retry errors such as code 40001. Applications need client-side retry loops to handle them gracefully.
Is Spanner always pessimistic?
No. Spanner’s default concurrency is pessimistic locking, but it also offers an optional optimistic mode for read-write transactions. Teams that want to avoid waiting under contention can opt in, at the cost of handling conflicts themselves.
Which database is easiest to configure for multiple regions?
It depends on your team’s habits. CockroachDB puts region topology into SQL statements, so it lives in migrations and pull requests. Spanner uses instance configuration and database creation options, which sits closer to infrastructure provisioning. Neither is objectively easier.
Can I assume PostgreSQL compatibility across all three?
No. Compatibility claims are vendor-defined and vary in depth. CockroachDB and Aurora DSQL target PostgreSQL wire and dialect compatibility, while Spanner offers a PostgreSQL-dialect interface with GoogleSQL as its default. Always validate with your own driver and ORM test suite.
Are the 2027 workflow differences predictable?
Only partly. The structural choices, such as optimistic versus pessimistic concurrency and where region configuration lives, are architectural and likely to persist. Specific features and general availability timing are not public, so re-verify against current documentation before making a decision.
One final point deserves emphasis: none of these three systems is a drop-in replacement for a single-node PostgreSQL instance, and pretending otherwise is where migrations go wrong. Treat the move as an application redesign with a database attached, not a connection-string swap. Budget time for retry logic, region topology decisions, and schema-change testing before you write a line of production code. If you take one habit from this comparison, make it this: prototype with your own workload, your own ORM, and your own contention patterns, then let the evidence choose the database rather than the marketing page.
