Skip to content

SYSTEM Cited by 1 source

Aurora PostgreSQL Limitless Database

What it is

Amazon Aurora PostgreSQL Limitless Database is AWS's horizontally-scaled, PostgreSQL-compatible offering within the Aurora family: a single logical Postgres database that transparently shards compute and storage across multiple nodes under the hood, while exposing a conventional Postgres SQL / wire-protocol surface. Announced as a preview and positioned as the "sister" scale-out story to systems/aurora-dsql — DSQL is the fresh-ground-up distributed-SQL design; Limitless is the horizontally-scaled evolution of classic Aurora.

Why it shows up on this wiki

Limitless is named in AWS's 2025-05-03 response to Jepsen's Postgres Multi-AZ analysis as one of the two AWS offerings that does not exhibit the Long Fork anomaly that community Postgres + RDS Multi-AZ both exhibit. The reason is architectural, not operational:

"Aurora Limitless and Aurora DSQL implement consistent snapshots using time-based Multi-Version Concurrency Control (MVCC) instead, which avoids the Long Fork anomaly." — (Source: sources/2025-05-03-aws-postgresql-transaction-visibility-read-replicas)

That sentence is load-bearing. Community Postgres uses ProcArray-based visibility: a snapshot records the in-flight xid set and excludes those tuples, with visibility removal asynchronous w.r.t. WAL commit. That decoupling is why concepts/visibility-order-vs-commit-order can skew and admit Long Fork. Limitless replaces that substrate with time-based MVCC: snapshots are identified by a clock value, and a tuple is visible to a snapshot iff its commit time ≤ the snapshot time. Obtaining a consistent snapshot across the shards of a distributed Postgres becomes a clock read, not a fanned-out gather of every node's ProcArray. The latter is what AWS calls "practically infeasible" at scale; the former is the architectural escape hatch.

This positions Limitless alongside DSQL as the second AWS instance of patterns/postgres-extension-over-fork at the visibility layer — keep the parser/planner, replace the concurrency-control substrate via Postgres's public extension API.

Relationship to Aurora DSQL

Both Limitless and DSQL scale Postgres writes horizontally; both sidestep Long Fork via time-based MVCC; both live in the Aurora family. Differences are architectural lineage, not consistency model:

  • systems/aurora-dsql — ground-up redesign. Single-journal-per-commit (no 2PC), Crossbar router between journals and storage, full Rust implementation. Multi-region from day one.
  • Aurora Limitless — horizontal-scale evolution of Aurora PostgreSQL's existing cloud-optimized storage; preserves more of the classic Aurora storage tier.

Both are instances of the same pattern: Postgres via extension, replace the pieces that don't scale, keep the parts (SQL, parser, planner, ecosystem) that do. (Source: sources/2025-05-03-aws-postgresql-transaction-visibility-read-replicas plus sources/2025-05-27-allthingsdistributed-aurora-dsql-rust-journey for the DSQL counterpart.)

Time-based MVCC vs ProcArray

The relevant contrast, in one table:

Community Postgres (RDS, self-managed) Aurora Limitless / DSQL
Snapshot mechanism Scan ProcArray for in-flight xids Read a clock value
Visibility order Asynchronous with WAL commit Tied to commit time
Long Fork Admits, at all isolation levels Absent
Distributed snapshot "Practically infeasible" across nodes Clock-read; natural to distribute
Per-snapshot CPU cost Measurable on 1000s of connections Avoids the ProcArray scan

Seen in

Last updated · 200 distilled / 1,178 read