Spanner vs Aurora PostgreSQL Limitless: Two Approaches to Horizontally Scaling PostgreSQL Workloads

When high-throughput systems hit the physical write limits of the largest single-node PostgreSQL instances, adding more read replicas can no longer mask the primary node’s CPU saturation. At this threshold, architects realize they need a horizontally sharded database. However, implementing manual sharding at the application layer risks breaking strict ACID compliance. The industry has introduced managed solutions that promise limitless write scaling while maintaining the PostgreSQL interface: Google Cloud Spanner and Amazon Aurora PostgreSQL Limitless Database. While both abstract the pain of sharding, they take completely different architectural paths to achieve distributed consensus, resulting in vastly different operational limits.

Situation

Consider an enterprise financial platform managing millions of accounts.

Payment API
     |
     | (100k+ TPS, strict serializability)
     |
Standard Single-Node PostgreSQL
     |
100% CPU / I/O Bottleneck

The platform needs to transition to a horizontally scaled architecture without rewriting their ORM. It needs cross-shard transactional consistency—if User A (on Shard 1) sends money to User B (on Shard 2), the database must guarantee a two-phase commit (2PC) that prevents double-spending. It also requires high availability across multiple zones. The architecture must choose between Cloud Spanner (using the PostgreSQL interface) and Aurora PostgreSQL Limitless Database.

The Problem

Traditional horizontal sharding is a nightmare for DBAs. If you use an extension like Citus or implement application-level sharding, you are responsible for schema deployment across shards, cross-shard query routing, and rebalancing data when a single shard becomes a “hotspot.”

Managed solutions attempt to hide this complexity behind a single endpoint. However, the laws of physics and distributed systems (the CAP theorem) still apply. When a transaction spans multiple shards, the system must coordinate those shards over a network. This introduces clock skew and network latency. If an architect assumes a distributed transaction on Spanner or Aurora Limitless performs exactly like a local transaction on a single monolithic PostgreSQL node, their application will grind to a halt waiting for network consensus or suffering from ABORTED lock errors.

The core question is: How do Spanner and Aurora Limitless internally coordinate distributed transactions, and what does that mean for schema design and query latency?

Distributed Write Architecture Comparison

Both databases provide a single PostgreSQL-compatible connection endpoint, but their internal topologies differ significantly.

flowchart TD
    subgraph Amazon Aurora Limitless
    A_App[Client] --> A_Router[Router Node]
    A_Router -- 2PC — AWS Time Sync --> A_Shard1[Shard 1 — PostgreSQL]
    A_Router -- 2PC — AWS Time Sync --> A_Shard2[Shard 2 — PostgreSQL]
    A_Shard1 --> A_Storage[(Aurora Storage Fleet)]
    A_Shard2 --> A_Storage
    end
    
    subgraph Google Cloud Spanner
    G_App[Client] --> G_API[Spanner API Coordinator]
    G_API -- 2PC — TrueTime --> G_Split1[Split 1 — Paxos Group]
    G_API -- 2PC — TrueTime --> G_Split2[Split 2 — Paxos Group]
    G_Split1 --> G_Colossus[(Colossus)]
    G_Split2 --> G_Colossus
    end

Google Cloud Spanner (PostgreSQL Interface)

Spanner is a proprietary distributed database built from the ground up on Paxos consensus, with the PostgreSQL interface as a translation layer over it — see How Google Cloud Spanner Scales Writes for the full split/Paxos/TrueTime write path. The point that matters for this comparison: Spanner uses a Commit-Wait mechanism, where the transaction coordinator waits out TrueTime’s clock uncertainty window before acknowledging a cross-split commit.

Amazon Aurora PostgreSQL Limitless Database

Aurora Limitless is built on fleets of actual PostgreSQL instances. It introduces a two-layer architecture: Routers (which parse queries and manage distributed transactions) and Shards (standard Aurora PostgreSQL nodes that hold partitioned data). To solve the distributed transaction problem, Limitless relies on AWS Time Sync and hybrid logical clocks. Similar to TrueTime, it assigns globally comparable timestamps to order cross-shard transactions. The exact overlap between Limitless’s commit-wait handling and Aurora’s quorum storage write path is an implementation detail worth confirming against current AWS documentation rather than assuming from Spanner’s design — the operationally relevant point is the same either way: cross-shard transactions pay a clock-uncertainty tax that local-shard transactions don’t.

In Practice

The documented operational patterns for these databases require different DBA strategies.

Schema Design and Shard Keys

Aurora Limitless: Requires you to explicitly define how tables are distributed, but not through a SHARDED DDL keyword — table distribution mode is set via session variables before a standard CREATE TABLE:
```
SET rds_aurora.limitless_create_table_mode = 'sharded';
SET rds_aurora.limitless_create_table_shard_key = '{"customer_id"}';
CREATE TABLE orders (...);
```
You can also create REFERENCE tables (small tables copied to every shard for fast local joins) and collocated tables (sharded tables sharing a shard key so joins between them execute on a single shard, the direct Aurora-side analog to Spanner’s INTERLEAVE IN PARENT).
Spanner: Automatically manages splits. However, if your primary keys are sequential (e.g., SERIAL), Spanner will push all writes to a single split, creating a fatal hotspot. You must use UUIDv4 or bit-reversed sequences. You use INTERLEAVE IN PARENT to co-locate related tables (similar to a shard key).

PostgreSQL Compatibility

Aurora Limitless: Because the underlying shards run actual PostgreSQL, standard SQL and drivers work unmodified — but extension support is narrower than it sounds. Limitless supports a curated allowlist of roughly 15 extensions (including pgvector, PostGIS with limitations, pg_trgm, pgcrypto, and a handful of others), meaningfully fewer than the 70+ extensions available on standard (non-Limitless) Aurora PostgreSQL, since the distributed architecture restricts what can run safely across shards.
Spanner: The PostgreSQL interface is a protocol and syntax wrapper. It does not support many native PostgreSQL extensions (like PostGIS), triggers, or stored procedures.

Autoscaling

Aurora Limitless: The DB Shard Group operates in a serverless manner, automatically adjusting compute capacity across routers and shards based on workload demands.
Spanner: Storage scales automatically. Compute (Processing Units) can also autoscale — Spanner has a GA managed autoscaler on Enterprise and Enterprise Plus editions — but Standard edition, or Enterprise/Enterprise Plus with autoscaling disabled, still requires manual provisioning. This isn’t the clean “Aurora is serverless, Spanner isn’t” split it might appear to be; both now offer automated compute scaling, gated by edition and configuration rather than architecture.

Where It Breaks

Distributed databases cannot bend the speed of light.

Failure Mode	Detection	Mitigation / Tradeoff
Cross-Shard Join Latency	High query latency	A `JOIN` between tables on different shards/splits requires massive network data transfer. You must use Shard Keys (Aurora) or Interleaving (Spanner) to physically co-locate joined rows.
Spanner: Hotspots	Key Visualizer shows red bands	Sequential primary keys bottleneck the entire cluster on one node. Must refactor schema to use highly entropic keys (UUIDs).
Transaction Size Limits	`Transaction too large` errors	Spanner hard-limits transactions to 80,000 mutations or 100MB. Massive batch deletes must be chunked.
Contention Aborts	High `ABORTED` error rates	Spanner uses pessimistic two-phase locking with wound-wait. If multiple clients create a deadlock risk, younger transactions receive abort errors and must retry.

What to Do Next

When choosing between Spanner and Aurora Limitless for write scaling:

Problem: Single-node PostgreSQL compute cannot handle >100,000 write transactions per second, forcing a move to distributed architectures.
Solution: Both Spanner and Aurora Limitless offer managed horizontal scaling, utilizing atomic clock synchronization (TrueTime / AWS Time Sync) to coordinate cross-shard transactions without application-layer complexity.
Proof: Google and AWS documentation confirm that cross-shard distributed transactions require Commit-Wait mechanisms, making local shard co-location (via Shard Keys or Interleaving) mandatory for high performance.
Action: If your application heavily relies on native PostgreSQL extensions, triggers, or stored procedures, migrate to Amazon Aurora Limitless, as it runs actual PostgreSQL under the hood — but verify your specific extensions against the current allowlist first. If your application logic is externalized and you require zero-RPO multi-region consensus across continents, migrate to Cloud Spanner and rewrite your sequential primary keys to UUIDs.

Technical References

Google Cloud

AWS

Claims Requiring Additional Human Validation

The exact current count and list of Aurora Limitless-supported extensions should be re-checked against AWS’s DDL limitations page before publication-sensitive claims are made, since this is an allowlist AWS can expand over time.
Spanner’s managed autoscaler edition gating (Enterprise/Enterprise Plus only) should be re-verified if this post is updated significantly after August 2026, since edition feature gating is a common target for expansion.