Every distributed database vendor now claims to offer global scale with strong consistency, but the three products actually shipping that promise in production take wildly different paths to get there. Amazon Aurora DSQL bills by the Distributed Processing Unit and forces you to give up foreign keys. CockroachDB runs anywhere you can run a container and prices by the vCPU-hour. Google Cloud Spanner has powered Google’s own ad infrastructure since 2012 and now ships a graph engine bolted onto the same storage layer. Picking between them means picking a different set of trade-offs on latency, SQL compatibility, and the bill that shows up in September.
This comparison breaks down Amazon Aurora DSQL vs CockroachDB vs Google Cloud Spanner as they actually run in September 2026: real pricing per million requests, the SQL features each one silently drops, and which one survives a us-east-1 outage without you finding out at 3 a.m. If you are migrating off a single-region Postgres instance that has started to buckle under multi-region traffic, or you are choosing a distributed SQL database from scratch for a new service, this is the breakdown that matters.
Don't miss new tech stories on Google
Add Tech Insider once in the Google app and our stories appear in your news suggestions.
What “Distributed SQL” Actually Means in 2026
Distributed SQL databases, sometimes called NewSQL, promise the horizontal scalability of a NoSQL system without giving up ACID transactions and a SQL interface. Instead of a single primary node handling writes with read replicas trailing behind, these systems replicate data across multiple nodes (often across regions or continents) and use consensus protocols like Raft or Paxos to keep every replica consistent before a transaction is considered committed.
The category exists because two older approaches both fail at scale. Traditional single-primary databases like standalone PostgreSQL or MySQL top out on vertical scaling and create a single point of failure. Sharded NoSQL systems scale horizontally but force developers to give up joins, multi-row transactions, and the tooling ecosystem built around SQL. Distributed SQL tries to have both, and by 2026, three products have matured enough for production use at meaningful scale: Amazon Aurora DSQL, CockroachDB, and Google Cloud Spanner.
Each one solves the consensus problem differently. Spanner uses Google’s proprietary TrueTime API, which relies on atomic clocks and GPS receivers in Google’s own data centers to bound clock uncertainty tightly enough to order transactions globally. CockroachDB implements a similar idea in software using hybrid logical clocks, so it can run on any infrastructure without needing custom hardware. Aurora DSQL, AWS’s newest entrant, uses a disaggregated architecture that separates transaction processing from storage entirely, journaling writes to a separate durability layer before applying them.
That architectural split matters more than it sounds like on paper. A database that depends on specialized clock hardware, as Spanner originally did, can only run inside the infrastructure that has that hardware installed, which is why Spanner has stayed a Google Cloud-exclusive product for over a decade. A database built on hybrid logical clocks in software trades a small amount of coordination overhead for the freedom to run on commodity infrastructure anywhere, which is exactly the bet CockroachDB made from its first release. And a database that disaggregates compute from storage entirely, as Aurora DSQL does, can scale each layer independently and bill for them separately, which is what makes true scale-to-zero possible in a way neither of the other two architectures supports today.
None of these are free choices. Every additional layer of consensus coordination adds latency to a write, and every architecture that spreads a single logical transaction across more physical machines adds more ways for a network partition, a slow disk, or a misconfigured region pairing to turn a routine commit into a multi-second stall. Understanding which trade-off each platform is optimized for is the difference between picking the right tool and discovering the hard way, months into production, that a workload’s access pattern fights the database’s underlying design.
Amazon Aurora DSQL: AWS’s Newest Distributed Database
Amazon Aurora DSQL reached general availability on May 28, 2025, and AWS describes it as “the fastest serverless, distributed SQL database with active-active high availability and multi-Region strong consistency,” according to the official AWS launch announcement. As of 2026, Aurora DSQL runs in 14 regions across four continents, up from the three-region footprint it launched with.
The headline feature is multi-Region active-active clusters: you can accept writes in two peer regions simultaneously (plus a third witness region for quorum), and Aurora DSQL replicates those writes with strong consistency guarantees across regions automatically. That is a meaningfully different architecture from Aurora’s older Global Database feature, which uses asynchronous replication from a single writer region.
The Catch: It Speaks PostgreSQL, But It Isn’t PostgreSQL
Aurora DSQL uses the PostgreSQL wire protocol and works with standard PostgreSQL drivers, ORMs, and the psql client. But it is blunt about the gap in a different sense: per AWS’s own unsupported-features documentation, it runs only a subset of PostgreSQL 16 syntax and behavior, and a 2026 technical analysis on Security Boulevard put it plainly: it runs “a PostgreSQL 16-compatible subset with significant feature limitations required by its distributed architecture.” A PostgreSQL driver connecting successfully to Aurora DSQL only proves protocol compatibility, not that your application’s transaction semantics will work unchanged.
The list of what’s missing is long enough to change how you design a schema. There is no SERIALIZABLE isolation level (transactions run at a fixed REPEATABLE READ). Triggers, views, materialized views, stored procedures, and PL/pgSQL are all unsupported, meaning business logic that lived in the database has to move into the application layer. Sequences and SERIAL/BIGSERIAL columns don’t exist, so primary keys need to be generated as UUIDs instead. Extensions including PostGIS, pgvector, and pgcrypto are not supported. Temporary tables and explicit row locking (SELECT FOR UPDATE) are also off the table, and a single transaction is capped at roughly 3,000 modified rows, which rules out large batch updates without restructuring the workload.
Foreign key support, long the most-requested missing feature, only landed on August 26, 2026, according to a detailed Aurora DSQL design decision guide. Until an application has been rebuilt around these constraints, migrating an existing PostgreSQL codebase to Aurora DSQL is closer to a rewrite than a lift-and-shift.
In practice, a schema written for standard PostgreSQL has to change shape before it runs cleanly on Aurora DSQL. A typical auto-incrementing primary key definition has to be rewritten to generate its own identifiers:
-- Standard PostgreSQL: works on CockroachDB and Spanner's PostgreSQL dialect
CREATE TABLE orders (
id SERIAL PRIMARY KEY,
customer_id INT REFERENCES customers(id),
created_at TIMESTAMP DEFAULT now()
);
-- Aurora DSQL equivalent: no SERIAL, no foreign key pre-Aug 2026, UUID required
CREATE TABLE orders (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
customer_id UUID NOT NULL,
created_at TIMESTAMP DEFAULT now()
);
-- Referential integrity to customers(id) must be enforced in application code
-- if running on an Aurora DSQL cluster created before August 26, 2026That single change (dropping SERIAL for a UUID default) is usually the first thing a migration script has to fix, and it cascades into every place the application code assumes an integer, auto-incrementing ID.
Aurora DSQL Pricing: The DPU Model
Aurora DSQL bills everything (compute, reads, writes, change-data-capture streaming, and cross-region replication) through a single normalized unit called the Distributed Processing Unit, or DPU. AWS’s own Aurora DSQL pricing page confirms the meter tracks ComputeDPU, ReadDPU, WriteDPU, StreamDPU, and MultiRegionWriteDPU separately in CloudWatch, but bills them at one unified rate.
In US East (N. Virginia and Ohio), that rate works out to roughly $8 per 1 million DPUs, or about $0.33 per DPU-hour for compute, read, write, and streaming activity, plus $0.33 per GB-month for storage. AWS offers a free tier covering the first 100,000 DPUs and 1 GB-month of storage per month, which one practitioner estimate puts at roughly 700,000 TPC-C-style transactions before charges start. The database also scales to zero when idle, so an unused cluster generates no DPU charges at all.
The sting is in multi-region clusters. Every write that gets replicated to a peer region incurs a MultiRegionWriteDPU charge equal to the cost of the original write, according to AWS’s Aurora DSQL user guide. That means a two-region active-active cluster roughly doubles the DPU cost of every write compared to a single-region deployment, on top of the unpredictability of a usage-based meter that most teams have no established intuition for estimating in advance.
CockroachDB: The Portable Option
CockroachDB, built by Cockroach Labs, takes the opposite approach from Aurora DSQL on portability: it runs self-hosted on any Kubernetes cluster, any cloud, or bare metal, in addition to the fully managed CockroachDB Cloud offering. The latest major release, CockroachDB v26.3, reached general availability on August 19, 2026, following v26.1 in April and v25.3 in the preceding months, according to Cockroach Labs’ own release notes.
Architecturally, CockroachDB shards data into ranges of roughly 512 MB, replicates each range using the Raft consensus protocol (typically to three or five nodes), and uses hybrid logical clocks rather than specialized hardware to order transactions across the cluster. That software-only approach to clock synchronization is the main reason CockroachDB can run anywhere, unlike Spanner’s original dependency on Google’s TrueTime infrastructure.
CockroachDB Cloud Pricing Tiers
Cockroach Labs sells CockroachDB Cloud in three tiers. Basic is the serverless, consumption-based option: the free plan includes 10 GB of storage and 50 million Request Units per month, and the paid version above that charges $0.20 per 1 million Request Units plus $0.50 per GB-month of storage, based on a 2026 pricing review verified against Cockroach Labs’ published rate card. Standard is a provisioned, per-vCPU-hour plan starting around $0.50 per vCPU-hour for multi-AZ high availability, and Advanced, aimed at multi-region and compliance-sensitive workloads such as PCI or HIPAA environments, starts around $0.95 per vCPU-hour. Self-hosted CockroachDB Enterprise is licensed separately, typically in the range of $1,400 to $2,200 per vCPU per year as an annual subscription.
Unlike Aurora DSQL’s all-inclusive DPU meter, CockroachDB’s tiered structure means the actual bill depends heavily on which tier fits the workload. A bursty, low-traffic application can live entirely on the free Basic tier, while a steady-state, high-throughput service is usually cheaper on a provisioned vCPU-hour plan than a pure consumption model.
Google Cloud Spanner: The Incumbent
Spanner has the longest track record of the three. Google has run it internally since 2012, and it powers core Google infrastructure including the ad platform that generates the bulk of Alphabet’s revenue. That operational history is Spanner’s biggest selling point: over a decade of production hardening at a scale neither Aurora DSQL nor CockroachDB has been proven at yet.
In 2024, Google restructured Spanner’s pricing and packaging into three editions, and it has continued extending them through 2025 and 2026. Standard edition covers relational (GoogleSQL and PostgreSQL-dialect) and key-value workloads. Enterprise edition adds multi-model capabilities, including Spanner Graph, full-text search, and vector search, on top of the same storage engine, according to Google’s Spanner editions announcement. Enterprise Plus adds up to 99.999% availability SLA for multi-region configurations and geo-partitioning support, positioned for the most latency- and downtime-sensitive global applications, per the Spanner editions overview documentation.
A 2025 Spanner product update from Google Cloud also confirmed that Spanner Graph now supports schemaless data, letting teams iterate on graph models without requiring a schema migration for every change, which brings Spanner closer to a genuinely multi-model database rather than a relational store with graph features bolted on.
Spanner Pricing: Per-Replica Billing
The 2024 editions overhaul also changed how Spanner bills. Google moved to per-replica (per-server) billing that decouples compute cost from data replication cost, which is meant to make multi-region deployments more predictable to price out. Compute capacity is measured in processing units (1,000 processing units equal one full node), and 2026 pricing shows Enterprise edition starting around $0.041 per 100 processing units per hour per replica, with Enterprise Plus starting around $0.057 per 100 processing units per hour per replica.
Because Spanner bills per replica across however many regions a configuration spans, a three-region multi-region instance costs meaningfully more than a single-region one, similar in spirit to Aurora DSQL’s MultiRegionWriteDPU surcharge, but calculated on provisioned capacity rather than per-write consumption.
Aurora DSQL vs CockroachDB vs Spanner: Full Specs Comparison
| Attribute | Amazon Aurora DSQL | CockroachDB | Google Cloud Spanner |
|---|---|---|---|
| GA date | May 28, 2025 | 2017 (v26.3: Aug 19, 2026) | 2017 public GA (internal since 2012) |
| SQL dialect | PostgreSQL 16-compatible subset | PostgreSQL wire protocol, own dialect | GoogleSQL or PostgreSQL dialect |
| Deployment model | AWS-managed only, serverless | Self-hosted or CockroachDB Cloud | Google Cloud-managed only |
| Consensus mechanism | Disaggregated journal/storage layer | Raft with hybrid logical clocks | Paxos with TrueTime atomic clocks |
| Multi-region writes | Active-active, 2 peer regions + witness | Active-active, any region count | Active-active, any region count |
| Foreign keys | Added Aug 26, 2026 | Fully supported | Fully supported |
| Triggers / stored procs | Not supported | Supported | Not supported (uses GoogleSQL functions) |
| Isolation level | Fixed REPEATABLE READ | Serializable (default) | External consistency (strongest) |
| Regions available (2026) | 14 regions | All major clouds/regions (self-hosted) | 40+ Google Cloud regions |
| Scale-to-zero | Yes (serverless) | Yes (Basic tier only) | No (provisioned capacity) |
| Vector/AI search | Not supported | Not supported natively | Yes (Enterprise edition) |
| Graph queries | Not supported | Not supported natively | Yes (Spanner Graph, Enterprise) |
| Free tier | 100K DPUs + 1GB/mo | 10GB + 50M RU/mo | No free tier for production editions |
Pricing Breakdown: What a Mid-Size Workload Actually Costs
Sticker prices are hard to compare directly across three different billing units (DPUs, Request Units, and processing units), so the table below normalizes each platform’s published 2026 rate card against a few reference points.
| Pricing dimension | Amazon Aurora DSQL | CockroachDB Cloud | Google Cloud Spanner |
|---|---|---|---|
| Entry-level free tier | 100,000 DPUs/mo + 1 GB storage | 10 GB storage + 50M RU/mo (Basic) | None on paid editions |
| Base compute rate | ~$8 per 1M DPUs (~$0.33/DPU-hr) | $0.20 per 1M RU (Basic paid) | $0.041/100 PU-hr (Enterprise) |
| Provisioned compute alt. | N/A (usage-only) | ~$0.50/vCPU-hr (Standard) | $0.057/100 PU-hr (Enterprise Plus) |
| Storage cost | $0.33/GB-month | $0.50/GB-month (Basic) | Billed separately per edition |
| Multi-region write surcharge | Full extra DPU charge per replicated write | None (included in vCPU pricing) | Extra per-replica compute charge |
| Self-hosted / on-prem option | No | Yes, ~$1,400-$2,200/vCPU/year | No |
| Billing predictability | Low (usage-metered, hard to forecast) | High (provisioned tiers available) | Medium (provisioned but per-replica) |
The practical takeaway: Aurora DSQL rewards genuinely spiky, low-baseline workloads that benefit from scale-to-zero, since an idle cluster costs nothing. CockroachDB’s Standard and Advanced tiers reward steady, predictable traffic where a fixed vCPU-hour rate beats a consumption meter. Spanner’s per-replica model sits in between, but its lack of a meaningful free tier on production editions makes it the most expensive starting point for a small team testing the waters.
Performance and Latency: What Independent Testing Shows
Head-to-head, apples-to-apples throughput benchmarks across all three platforms in their current 2026 form are hard to find, and any vendor-published number should be read with that vendor’s incentive in mind. That said, several independent and semi-independent sources give a usable picture.
Cockroach Labs’ own comparison page, CockroachDB vs Amazon Aurora and DSQL, argues that CockroachDB’s Raft-based replication delivers more predictable tail latency under multi-region write load than Aurora DSQL’s disaggregated journal design, though as a vendor comparison it should be treated as a starting point for your own testing rather than a final verdict. Separately, a widely-read technical breakdown from AWS engineer Marc Brooker, posted to X in 2026, noted that “Aurora DSQL and Spanner have relatively little in common” architecturally despite both being marketed as globally consistent distributed SQL databases, since Spanner leans on custom TrueTime hardware while Aurora DSQL’s consistency model is built entirely on commodity infrastructure.
A third data point comes from YugabyteDB’s own benchmark writeup comparing YugabyteDB, CockroachDB, and Amazon Aurora on write performance, scaling reads and writes, and connection scaling under a standardized test harness. While that benchmark centers a different distributed SQL competitor, its methodology (measuring write latency as node count and region count both increase) is a useful framework for evaluating Aurora DSQL and Spanner using your own workload, since none of the three vendors publish a neutral, third-party TPC-C or TPC-DS result that includes all three products together.
The practical guidance from most of these sources converges on the same point: single-region read latency is broadly comparable across all three (low single-digit milliseconds for point reads), but multi-region write latency diverges sharply based on how far apart the regions are and how each system’s consensus protocol handles the round-trip. Spanner’s TrueTime-based commit-wait mechanism adds a small, bounded delay to every transaction to guarantee external consistency, which is a deliberate trade of a few milliseconds of latency for a stronger consistency guarantee than either competitor defaults to.
It’s also worth separating two different kinds of latency that these benchmarks tend to blur together: intra-region latency, which measures how fast a single node cluster in one data center responds to reads and writes, and cross-region latency, which measures the cost of achieving consensus when the nodes voting on a transaction are physically hundreds or thousands of miles apart. All three platforms perform well on the first measure. The gap between them widens on the second, and it widens further still the farther apart the regions in a deployment actually are, since the underlying physics of speed-of-light network round trips sets a hard floor that no amount of software optimization can beat. A cluster spanning US-East and US-West will see meaningfully different write latency than one spanning US-East and a European region, regardless of which of the three databases is running underneath it.
This is also where read replicas and follower reads matter in practice. CockroachDB and Spanner both support reading from a nearby replica with slightly relaxed freshness guarantees to avoid a cross-region round trip on every read, which can cut effective read latency dramatically for read-heavy workloads that can tolerate a few hundred milliseconds of staleness. Aurora DSQL’s newer architecture supports a comparable pattern through its read-scaling model, but because the product has a shorter track record, fewer independent teams have published real-world numbers on how well that holds up under the kind of sustained, high-concurrency read load that a mature e-commerce or ad-serving platform generates daily.
Real-World Examples: Who Is Actually Running These in Production
Vendor case studies always come with a promotional angle, but they’re still the best public window into how these databases perform outside a benchmark lab. Here are five documented, named deployments across the three platforms.
Deutsche Bank / Postbank on Spanner. Deutsche Bank partnered with Google Cloud to modernize its Postbank online banking platform, migrating off on-premises infrastructure. According to a Google Cloud case study, the first production instance of the new platform, backed by Spanner, serves 5 million Postbank customers, making it one of the largest named retail-banking deployments of Spanner publicly documented.
Netflix on CockroachDB. Netflix runs a fleet of more than 380 CockroachDB clusters supporting globally distributed, always-on services, according to Cockroach Labs’ customer page. That cluster count, rather than a single flagship deployment, illustrates how CockroachDB gets adopted incrementally across many teams inside a large organization rather than as one monolithic migration.
FanDuel’s financial ledger on CockroachDB. Sports betting platform FanDuel uses CockroachDB to scale its financial ledger, a workload where correctness and availability under heavy concurrent load are non-negotiable. Cockroach Labs lists FanDuel alongside Route, a package-tracking company whose case study states CockroachDB powers “always-on data for 1+ billion orders and counting,” giving a concrete sense of the transaction volumes these deployments handle in production.
Razorpay evaluating Aurora DSQL for fintech. When AWS announced the Aurora DSQL preview, the company named several early evaluators including Autodesk, Electronic Arts, Klarna, and Razorpay, according to an AWS press release. Razorpay specifically said it planned to use Aurora DSQL’s multi-Region strong consistency to power new fintech products, an early signal of how payment companies are evaluating the newest of the three platforms.
Shenzhen Hexinzhilian on Aurora DSQL. A schedule-management application built by Shenzhen Hexinzhilian Technology Development, serving millions of users, reported a 60% improvement in development efficiency after adopting Aurora DSQL, since its serverless, PostgreSQL-compatible design meant the team didn’t need a dedicated database administrator, according to AWS’s Aurora DSQL product page. The same case study reported consistent millisecond response times under high concurrency and 99.99% single-Region availability.
Real-World Use Cases: Which Database Fits Which Workload
The right choice depends heavily on the shape of the workload, the existing cloud commitment, and how much SQL feature loss a team can tolerate. Here are five scenarios that map cleanly to one of the three platforms.
- New greenfield service already on AWS with unpredictable traffic: Aurora DSQL’s scale-to-zero billing and native integration with the rest of the AWS ecosystem (IAM, VPC, CloudWatch) make it the path of least resistance, as long as the schema can be designed around its PostgreSQL feature gaps from day one rather than retrofitted later.
- Multi-cloud or on-prem requirement, or avoiding vendor lock-in: CockroachDB is the only one of the three that runs anywhere, including bare metal and other clouds, which matters for regulated industries or companies with an explicit multi-cloud mandate.
- Existing large-scale PostgreSQL application with foreign keys, triggers, and stored procedures: CockroachDB’s broader PostgreSQL compatibility (including foreign keys and triggers) means a substantially smaller rewrite than migrating the same application to Aurora DSQL.
- Global consumer application already built on Google Cloud with a need for graph or vector search alongside transactional data: Spanner’s Enterprise edition, with Spanner Graph and vector search running against the same consistent transactional store, avoids running a separate graph or vector database alongside the primary one.
- Financial services or e-commerce platform needing the strongest available consistency guarantee across regions: Spanner’s decade-plus track record at Google’s internal scale, combined with its Enterprise Plus 99.999% SLA, gives risk-averse teams the longest audit trail of production use to point to.
Migration Guide: Moving to a Distributed SQL Database
Migrating an existing single-region relational database to any of these three platforms follows a similar overall shape, even though the specific tooling differs. Here is the general sequence, with platform-specific notes called out.
- Audit for unsupported features first. Before writing any migration code, run a static analysis of your schema and query patterns against the target platform’s unsupported-feature list. For Aurora DSQL, that means searching for triggers, stored procedures, sequences, foreign keys (pre-August 2026), and any use of extensions like PostGIS or pgvector.
- Redesign primary keys around UUIDs where sequences are unsupported. Aurora DSQL requires this change since
SERIALandBIGSERIALcolumns don’t exist; CockroachDB and Spanner both support sequence-like behavior but often recommend UUIDs anyway to avoid hotspotting on a single range during high write throughput. - Move business logic out of the database, if targeting Aurora DSQL or Spanner. Any logic living in triggers or stored procedures needs to move into the application layer or an event-driven pipeline (EventBridge, Pub/Sub, or similar), since neither platform supports server-side procedural code.
- Restructure large transactions to respect row-count limits. Aurora DSQL caps transactions at roughly 3,000 modified rows and requires DDL and DML to run in separate transactions. Batch jobs and bulk imports need to be chunked accordingly.
- Run a dual-write or change-data-capture pipeline during cutover. Use each platform’s native CDC support (Aurora DSQL’s StreamDPU-metered streaming, CockroachDB’s changefeeds, or Spanner’s change streams) to replicate data to the new system while the old one stays authoritative.
- Load-test multi-region write latency before committing to an architecture. Because all three platforms charge extra for cross-region writes and each handles consensus differently, synthetic load tests against your actual region pairs will reveal real latency numbers faster than any published benchmark.
- Validate isolation-level assumptions in application code. Code written assuming PostgreSQL’s default
READ COMMITTEDisolation may behave differently under Aurora DSQL’s fixedREPEATABLE READor Spanner’s external consistency model; concurrency bugs here are often silent until production load exposes them. - Cut over incrementally by service, not database-wide. Migrating one microservice’s data store at a time limits blast radius if an unsupported feature or unexpected latency pattern surfaces post-migration.
Pros and Cons
Amazon Aurora DSQL
Pros: Scale-to-zero billing means no cost for idle workloads; tight native integration with the rest of AWS; a genuinely serverless operational model with no capacity planning; a usable free tier for prototyping.
Cons: Newest of the three with the shortest production track record (GA in May 2025); the largest gap between “PostgreSQL-compatible” marketing and actual feature support; usage-based DPU billing is difficult to forecast; locked into AWS only; 3,000-row transaction cap complicates batch workloads.
CockroachDB
Pros: Runs anywhere (self-hosted, any cloud, CockroachDB Cloud); the broadest PostgreSQL compatibility of the three, including foreign keys, triggers, and stored logic; predictable provisioned pricing tiers alongside a consumption option; mature open-source core with nearly a decade of releases.
Cons: No native vector or graph engine built into the core product; self-hosted deployments require real operational expertise to run well; Enterprise self-hosted licensing is priced per vCPU-year and can get expensive at scale; multi-region latency still depends heavily on region placement and quorum design.
Google Cloud Spanner
Pros: Longest production track record of any distributed SQL system, running inside Google since 2012; strongest available consistency guarantee via TrueTime; Enterprise edition bundles graph and vector search onto the same transactional store; up to 99.999% SLA on Enterprise Plus.
Cons: Locked into Google Cloud only; no meaningful free tier for production editions, making small-scale experimentation more expensive than the other two; per-replica pricing across regions adds up quickly for wide multi-region footprints; the editions restructuring in 2024-2026 means older pricing guides and tutorials are now outdated.
Market Context: Why Distributed SQL Matters Now
The push toward distributed SQL databases tracks a broader shift in how applications get built: more services need to serve users across multiple continents with low latency, more compliance regimes require data to stay resident in specific geographies, and more teams have grown wary of the operational fragility of a single-writer relational database as a company’s sole source of truth. Aurora DSQL’s launch in 2025 was itself a signal that AWS, historically content to let Aurora’s read-replica architecture cover most multi-region use cases, saw enough demand for true multi-writer consistency to build an entirely new product rather than extend Aurora further.
Google’s 2024-2026 Spanner editions overhaul tells a similar story from the other direction: after over a decade as effectively the only production-proven globally distributed SQL database, Spanner faced enough competitive pressure from CockroachDB and, more recently, Aurora DSQL, that Google restructured pricing to be more transparent and added multi-model features (graph, vector, full-text search) to broaden Spanner’s appeal beyond pure OLTP workloads. That competitive dynamic, three well-funded platforms actively iterating on the same problem within an 18-month window, is good news for anyone evaluating this category right now, since all three have been forced to ship real improvements rather than coast on an established position.
The Verdict
There is no universal winner here, and any comparison that claims one exists is oversimplifying a genuinely workload-dependent decision. But the data points in a fairly clear direction for three common situations.
If your team is already deep in AWS, your traffic is spiky rather than steady, and you can design your schema from scratch around Aurora DSQL’s PostgreSQL subset, its scale-to-zero billing and native AWS integration make it the cheapest and lowest-friction option, provided you accept a shorter production track record and a 3,000-row transaction ceiling. If you need the broadest SQL compatibility, the ability to run outside a single cloud, or you’re migrating an existing PostgreSQL application with foreign keys and triggers intact, CockroachDB requires the least rework and gives you the most deployment flexibility, at the cost of needing to run and tune the infrastructure yourself unless you pay for CockroachDB Cloud. And if you need the strongest possible consistency guarantee, want graph and vector search running against the same transactional data, or you’re building for a scale where a decade of production hardening actually matters, Spanner remains the most battle-tested choice, even though it carries the highest cost floor of the three and locks you into Google Cloud.
The safest first step for any team evaluating this category in September 2026 is the same regardless of which platform looks best on paper: run a real load test against your actual multi-region traffic pattern before committing, since the published benchmarks and pricing calculators from all three vendors optimize for scenarios that may not resemble your workload at all.
For more on managed database and cloud data infrastructure choices, see our comparisons of Amazon Aurora vs RDS, DynamoDB vs MongoDB, SQL vs NoSQL, PostgreSQL vs SQL Server, and Redshift vs Snowflake vs BigQuery, or browse more cloud computing coverage.
Frequently Asked Questions
Is Amazon Aurora DSQL a real PostgreSQL database?
No. Aurora DSQL speaks the PostgreSQL wire protocol and works with standard PostgreSQL drivers and clients, but AWS’s own documentation describes it as a “PostgreSQL 16-compatible subset” with significant feature gaps, including no triggers, no stored procedures, no sequences, and (until August 2026) no foreign keys. Treat it as a distributed SQL engine that happens to speak PostgreSQL’s protocol, not as managed PostgreSQL.
Can CockroachDB run outside the cloud?
Yes. CockroachDB is available as open-source and enterprise self-hosted software that runs on any Kubernetes cluster, virtual machines, or bare-metal hardware, in addition to the fully managed CockroachDB Cloud service. That portability is the main architectural difference from both Aurora DSQL and Spanner, which only run inside their respective vendor’s cloud.
Does Google Cloud Spanner have a free tier?
Spanner does not offer a meaningful free tier on its production Standard, Enterprise, or Enterprise Plus editions, unlike Aurora DSQL (100,000 free DPUs per month) and CockroachDB Cloud Basic (10 GB storage plus 50 million free Request Units per month). Small teams wanting to prototype on Spanner without cost will find Aurora DSQL or CockroachDB Cloud cheaper starting points.
Which of the three has the best multi-region write latency?
There is no single, neutral, third-party benchmark that tests all three platforms head-to-head under identical conditions in 2026. Vendor-published comparisons each favor their own product, and independent technical commentary suggests the architectures are different enough (TrueTime hardware-assisted clocks for Spanner, software hybrid logical clocks for CockroachDB, a disaggregated journal for Aurora DSQL) that the best approach is running your own load test against your actual region pairs rather than relying on a published number.
What happened to foreign keys in Aurora DSQL?
Foreign key support was the most requested missing feature in Aurora DSQL since its May 2025 general availability, and AWS added it on August 26, 2026, according to independent Aurora DSQL design guides. Before that date, referential integrity had to be enforced entirely in application code, which was one of the most disruptive gaps for teams migrating existing PostgreSQL schemas.
Do I need Spanner Enterprise edition for vector search?
Yes. Vector search and Spanner Graph, Google’s multi-model graph query capability, are both scoped to Spanner’s Enterprise and Enterprise Plus editions, not the base Standard edition. If your application only needs relational or key-value access patterns, Standard edition is cheaper and sufficient; if you need vector or graph queries against the same consistent data, you’ll need to provision Enterprise or above.
Is CockroachDB or Aurora DSQL cheaper for a small startup?
For genuinely low, spiky traffic, Aurora DSQL’s scale-to-zero model likely costs less since an idle cluster incurs zero DPU charges. For steady, predictable low-to-moderate traffic, CockroachDB Cloud’s Basic free tier (10 GB and 50 million Request Units per month) or its provisioned Standard tier can be cheaper and more predictable to budget for. The right answer depends on whether your traffic pattern is bursty or steady.
Related Coverage
- AWS vs Google Cloud: 28% vs 15% Share, 105% Perf Gap [2026]
- AWS ALB vs NLB vs Cloudflare LB: $16 vs $5 Gap [2026]
- AWS Outposts vs Azure Local vs GDC: 5-Yr Lock-In Gap [2026]
- CloudZero vs Vantage vs Kubecost: $449 FinOps Gap [2026]
- Unity vs GameAnalytics vs PlayFab: $499 Tier Gap [2026]
