If you need SQL across a growing, distributed workload, these three products offer different routes to that goal. Distributed SQL is a relational database approach that distributes data and transaction work across multiple nodes while presenting one SQL interface to applications. Each product targets horizontally distributed relational workloads, but cloud dependence, transaction behavior, and compatibility differ.
AWS announced Aurora DSQL at re:Invent 2024. Your choice can affect latency, application changes, and the work your team must handle. The right fit depends on your current cloud, workload conflict patterns, SQL needs, and operations capacity. This comparison helps you narrow the options without treating one database as right for every team.
Key Takeaways
- Aurora DSQL is the managed, serverless option for AWS-first teams.
- CockroachDB offers cloud and self-managed deployment choices.
- Spanner is Google Cloud’s managed distributed SQL database.
- Transaction retries and contention can shape application latency.
- SQL feature checks can reveal migration work early.
- Benchmark the same workload and regions before choosing.
Treat portability, transaction behavior, and the SQL your application already uses as the first three decision filters.
Aurora DSQL vs CockroachDB vs Spanner 2026: What Sets Them Apart?
The quickest distinction is where each product runs and who operates its infrastructure. The three options differ in deployment control and in how their clusters handle distributed work.
| Product | Deployment footprint | Operating model | Architecture signal |
|---|---|---|---|
| Aurora DSQL | AWS | Managed serverless | Separated write-path components |
| CockroachDB | Cloud or self-managed | Managed or self-operated | Distributed data with Raft replication |
| Spanner | Google Cloud | Managed service | Paxos-based replication |
This Aurora DSQL vs CockroachDB vs Spanner 2026 review points to three distinct choices: Aurora DSQL is the natural AWS-managed option, CockroachDB is the portability candidate, and Spanner is the managed Google Cloud option.
Aurora DSQL separates its write path into Query Processor, Adjudicator, Journal, and Storage components. A transaction becomes durable when its commit reaches the Journal. The design separates query work from other parts of the database.
CockroachDB spreads data across a cluster and uses Raft replication. Spanner uses Paxos groups to replicate data. A transaction that spans multiple Spanner groups uses two-phase commit.
AWS engineers describe the Aurora DSQL design in their Aurora DSQL technical paper. These design choices affect operations and transaction behavior, not just throughput.
Use the table to narrow your shortlist, not to substitute for testing your own transaction patterns.
The operating model also changes how much control you have over infrastructure. Managed services reduce day-to-day infrastructure work, while self-management gives you more direct control over deployment choices.
Cloud placement shapes which teams can use each product without changing their wider platform. That boundary can matter as much as the database’s internal design when your application already depends on one provider.
How Do Their Transaction Guarantees Differ?
A conflicting Aurora DSQL transaction can return a serialization error instead of waiting for a lock. That tradeoff favors optimistic work, but your application must handle the error. Isolation describes which results transactions can observe, while latency measures how long they take.
Aurora DSQL uses optimistic retries
Aurora DSQL uses optimistic concurrency control (OCC). It checks for conflicts as transactions commit, rather than relying on locks to hold conflicting work back.
When two transactions conflict, Aurora DSQL can return a serialization error. Your application needs retry logic that can safely rerun the affected transaction.
Keep retries bounded. A retry limit prevents one contested request from repeating without end, and backoff can keep rapid retries from adding pressure.
OCC can suit workloads with few conflicting writes. A hot record, such as one shared counter, can create repeated retries and change both throughput and response times.
CockroachDB uses serializable transactions
CockroachDB runs SQL transactions at the serializable isolation level. That level aims to make concurrent transactions behave as if they ran one at a time.
Raft consensus supports writes across CockroachDB’s distributed data. The guarantee does not remove the cost of contention: many writes to the same key can still compete.
Test hot-key contention with your own access patterns. A workload that spreads writes across many keys may behave differently from one that updates a small number of shared records.
Spanner offers more than one isolation level
Spanner supports serializable isolation, but it is not the only choice. Repeatable Read became generally available on April 17, 2026.
That option gives teams another way to set transaction behavior. Check that the selected isolation level matches the consistency needs of each operation.
Do not read an isolation label as a promise of lower latency. Network distance, coordination, and competing work also affect how long reads and writes take.
Spanner Repeatable Read availability gives teams a newer isolation choice, but it does not settle the performance question. Measure the effect with representative transactions.
Retries can also change the amount of work the cluster receives. A transaction that fails once and succeeds on a later attempt consumes more time than a single successful run.
Test retries with the application’s real conflict rate, since retry behavior can change both latency and throughput.
How Compatible Are Their SQL Features?
Check the SQL features your application actually calls, because broad PostgreSQL compatibility does not guarantee feature-for-feature portability. Small differences can force changes to schema design or application logic. Audit real queries and routines before estimating migration work.
Aurora DSQL’s PostgreSQL limits and transaction rules
An Aurora DSQL transaction can modify up to 3,000 rows across INSERT, UPDATE, and DELETE statements. The cap applies regardless of the number of secondary indexes.
DDL and DML must run in separate transactions. Aurora DSQL also allows only one DDL statement in a transaction, so a schema update with several changes needs separate steps.
A cluster has one built-in database named postgres. Use schemas for logical separation, or separate clusters when you need distinct database environments.
Aurora DSQL does not support temporary tables or procedural languages such as PL/pgSQL. Use a common table expression or subquery for temporary query results.
For procedural behavior, move the logic into the application layer. Foreign keys and JOIN operations are supported, so many relational queries can remain in the database.
Aurora DSQL uses UTF-8 encoding, C collation, and UTC system time. Connections time out after one hour, so applications should manage connection lifetimes.
The 3,000-row transaction limit applies to the combined row changes in those write statements. Count affected rows, not indexes, when checking whether a transaction fits.
Spanner’s dialects and recent SQL additions
Spanner supports GoogleSQL and PostgreSQL dialects. The two dialects do not make every application feature interchangeable, so match the chosen dialect to your code.
As of August 11, 2026, Spanner enforces an 80,000-mutation limit per DML statement. A transaction also faces a separate 100 MiB commit-size limit.
Approximate aggregate functions became available in both dialects on October 20, 2026. Spanner added ILIKE and NOT ILIKE support on September 3, 2026.
For PostgreSQL databases, vector indexes and approximate-nearest-neighbor distance functions became generally available on May 4, 2026. Queues became generally available on September 17, 2026.
Spanner tables can omit a user-defined primary key because Spanner creates a hidden rowid. That behavior differs from schemas that expect every table to declare its own key.
CockroachDB’s PostgreSQL-wire compatibility can help existing tools connect, but it does not promise zero migration work. Review application features and SQL behavior before moving data.
Inventory stored routines, temporary-table use, schema changes, and large write transactions before estimating migration effort.
How Do They Scale Across Regions and Failures?
Aurora DSQL’s single-Region availability spans several US regions and named locations in four other world regions as of May 2026. Regional reach differs by provider and deployment model. A listed region does not by itself confirm that a needed topology or capacity fits your design.
Regional availability and deployment reach
| Product | Provider or deployment reach | Regional detail | Operational distinction |
|---|---|---|---|
| Aurora DSQL | AWS | US East (N. Virginia), US East (Ohio), US West (Oregon), Canada (Central), Asia Pacific (Singapore), Europe (Ireland), South America (Sao Paulo), plus other listed locations | Managed service |
| CockroachDB | Cloud or self-managed | Depends on the operator’s chosen infrastructure | Designed to withstand disk, machine, rack, and datacenter failures without manual intervention |
| Spanner | Google Cloud | Google Cloud regions | Managed service |
Aurora DSQL is limited to AWS, and Spanner runs on Google Cloud. CockroachDB can run in cloud or self-managed environments, but each deployment depends on the operator’s chosen infrastructure.
That flexibility does not make every topology equal. Region count, network paths, and the way replicas are placed can change how a cluster behaves.
Failure handling and operational checks
CockroachDB is designed to withstand disk, machine, rack, and datacenter failures without manual intervention. Your team still needs to know how its chosen deployment handles recovery.
Use this four-part checklist when you review a proposed multi-region design:
- Replica placement across the regions you need.
- Behavior when a region fails during application traffic.
- Recovery validation through planned failure tests.
- Your team’s ability to operate the chosen topology.
Different designs can keep data available in different ways. A recovery plan should reflect the application’s tolerance for delayed requests and interrupted writes.
A team that chooses self-management also owns more of the surrounding infrastructure work. That includes keeping its operational skills aligned with the cluster design.
A cloud region comparison can help frame provider reach, but database service availability still depends on the specific product and location.
Verify the exact regions and failure-recovery behavior required by your application before committing to a topology.
What Drives the Total Cost?
A credible cost comparison starts with the workload and the full bill, not a single hourly compute number. Monthly cost reflects the resources, traffic, and people needed to run the database. Use current provider pricing tools with a representative workload.
Include these four inputs in each estimate:
- Compute or capacity.
- Storage growth.
- Network transfer or egress.
- Licensing and operations staffing.
Spanner pricing comparisons include node-hour, storage, and egress dimensions. Compute costs can vary by edition, region, and instance configuration.
CockroachDB Cloud pricing comparisons include vCPU-hour, storage, and I/O dimensions. Storage growth and traffic patterns can shift the bill beyond the compute line.
Check Aurora DSQL against its current AWS pricing model. Do not infer its cost from conventional Amazon Aurora pricing, since the products use different models.
Google Cloud’s Spanner pricing details include compute, storage, backups, replication, and network transfer. Those cost areas can matter when comparing a multi-region setup.
CockroachDB’s core license changed from Apache 2.0 to BSL in late 2024, with a four-year clock to Apache. The license restricts offering CockroachDB as a competing managed service.
That license change matters most to teams distributing a managed database service. It is not a blanket claim that CockroachDB is free or paid for every use.
Staff time belongs in the estimate, especially when your team operates infrastructure itself. Support needs and operational skills can change the full cost even when cloud usage looks similar.
Compare the same data volume, traffic pattern, regions, and support needs in each provider’s current pricing tools.
Which Performance Claims Hold Up?
A four-times-faster claim is a reason to benchmark the products, not a substitute for a workload-matched result. Measured performance changes with data placement, query shape, and contention. Amazon’s CEO described the result as an internal benchmark, not a universal head-to-head result.
The claim was that Aurora DSQL achieved reads and writes four times faster than Spanner in internal benchmarks. That result does not establish the same outcome for every application or deployment.
Cross-region write latency depends in part on network distance and coordination. A write that crosses regions has more distance to cover than one kept near its application.
Contention can change the result, too. Many writes to the same keys may behave differently from writes spread across the data.
Query shape and read locality also affect measured latency. A query that reads nearby data may have a different response time from one that reaches across regions.
Spanner direct connectivity became generally available on June 23, 2026. It routes application traffic directly to Spanner servers to reduce latency.
Direct connectivity is a latency-related capability, not a numeric speed guarantee. Its effect depends on how your application connects and where its traffic runs.
For a fair comparison, use the same schema, data distribution, and transaction mix. Keep region placement consistent so network distance does not favor one database.
Peak throughput alone can hide slow requests. Tail latency, measured as p95 and p99 latency, shows how slower requests behave under load.
Compare p95 and p99 latency under the same region placement and transaction mix before drawing a performance conclusion.
Which Database Fits Your Team and Workload?
The best default depends first on where your team wants to run the database and how much operational control it needs. Cloud posture and workload fit matter more than a presumed universal winner. Choose only among products that meet your required SQL and operating constraints.
Choose Aurora DSQL for AWS-first applications
Aurora DSQL is the clearest fit for AWS-first teams that want a serverless managed model. It can suit applications whose SQL needs fit its supported features.
Your application must also handle transaction retries. That work belongs in the design, not as a patch added after conflicts appear in production.
Teams already using AWS may find the provider alignment useful. Still, check whether the database’s SQL rules fit the application’s existing routines and write patterns.
Choose CockroachDB when portability matters
CockroachDB is a candidate when you need deployment portability or want to self-manage. It can run in cloud environments or on infrastructure your team operates.
That control takes engineering capacity. A distributed cluster still needs people who can manage its deployment, monitor its health, and respond to operational issues.
Portability may help teams avoid tying every database choice to one cloud provider. It does not remove the need to understand the limits of each deployment.
Choose Spanner for managed Google Cloud workloads
Spanner fits teams that value managed Google Cloud operations and need its SQL options. Its Google Cloud footprint can fit applications already built around that platform.
Check the SQL dialect and the transaction behavior your application needs. The right fit depends on those details, not on the service label alone.
The key tradeoff is cloud posture and workload fit, not a claim that one database wins in every case. Your team’s ability to operate the chosen model matters, too.
Cloud fit also affects how the database sits alongside your other services. This cloud provider comparison can help frame that wider platform choice.
Remove any option that fails a required cloud, SQL, or licensing constraint before running a proof of concept.
How Should You Test Them Before Choosing?
A useful proof of concept runs the same application-shaped workload against every finalist. Realistic tests reveal behavior that a simple peak-throughput run can miss. Use the same production-shaped schema, data distribution, and workload for all three products.
Reproduce your real workload
Include representative query shapes, indexes, data volume, and key distribution. Match the application’s read/write mix and transaction contention, rather than testing only clean, isolated queries.
A benchmark should test assumptions about locality and retries, not just peak throughput. For example, confirm that the application reads data near its users as expected.
Use this four-part evaluation list to keep the test grounded:
- Representative schema and data.
- Mixed read/write load.
- Conflict and retry behavior.
- Node or region failure recovery.
Compare tail latency, failures, and cost
Measure p95 and p99 latency under sustained load. Track both reads and writes so a fast average does not hide slow requests.
Run a failure test while transactions are active. Observe recovery and the effect on application requests, rather than testing an idle cluster.
Estimate cost using equal workload assumptions. Keep data volume, traffic pattern, regions, and support needs consistent across the finalists.
Set pass/fail thresholds for latency, recovery, and monthly cost before the test begins.
Record the query and transaction behavior that your application depends on. A clear test result should show whether those assumptions hold across the full run.
Set pass/fail thresholds for latency, recovery, and monthly cost before the test begins.
Conclusion
The right choice is the one that meets your cloud and SQL requirements without forcing your application to ignore its real transaction patterns. Cloud fit and SQL compatibility can eliminate poor candidates early.
For the remaining options, let transaction contention and workload-specific latency guide the decision. A database that fits your platform still needs to support the way your application reads and writes data.
Before making a long-term commitment, validate the finalist’s exact deployment regions and current pricing against your production assumptions.
FAQ
Are Aurora DSQL, CockroachDB, and Spanner all equally PostgreSQL-compatible?
No, the three products do not offer identical PostgreSQL behavior. Aurora DSQL supports a defined set of PostgreSQL features, while CockroachDB offers PostgreSQL-wire compatibility. Spanner has a PostgreSQL dialect alongside GoogleSQL. A connection protocol or dialect does not guarantee that every function, routine, or transaction will work unchanged. Compare the application’s actual SQL and schema needs.
What does Spanner’s 80,000-mutation limit apply to?
The 80,000-mutation limit applies to each DML statement, not the whole transaction. Spanner also has a separate 100 MiB transaction commit-size limit. The two limits measure different parts of a write operation, so a statement can meet its mutation cap while the overall transaction still exceeds its commit-size limit. Test large write batches with the actual statement structure.
Can a PostgreSQL application move to Aurora DSQL without code changes?
Not necessarily. A PostgreSQL application may rely on procedural behavior, temporary tables, or transaction patterns that Aurora DSQL does not support as written. Review stored routines, temporary-table use, and write sizes. Your application also needs suitable retry handling for serialization errors. A careful feature audit can show which code can stay and which parts need changes.
How should I estimate monthly cost before choosing a provider?
Model compute or capacity, storage growth, network transfer, licensing, and operations staffing. Use each provider’s current pricing tools with the same data volume, traffic pattern, regions, and support needs. Include backups or replication where the provider charges for them. A compute rate alone cannot show the full monthly cost, especially when network use or team effort differs.
Does Aurora DSQL’s four-times performance claim apply to every workload?
No. The four-times result was an internal benchmark claim, not a guarantee for every workload or deployment. Your result can change with query shape, data distribution, contention, and region placement. Benchmark all finalists using the same application-shaped workload and compare p95 and p99 latency. Keep the transaction mix and geography consistent so the comparison remains useful.
Is CockroachDB’s license relevant if I want to offer a database service?
Yes. CockroachDB’s core license moved from Apache 2.0 to BSL in late 2024, and the terms restrict offering it as a competing managed service. That restriction matters if your business plans to provide a database service to customers. Review the exact license terms for your intended use before building or selling that service.
