Announced last year at re:Invent 2023, Aurora Limitless (PostgreSQL compatible) is available in preview. If you didn't look at the preview, I'm starting a blog series so that you get some general information before getting more details from the re:Invent 2024 sessions about it. Here is the first post of this series.

Aurora Limitless is not a different engine. It is a managed sharding option built on top of Aurora Serverless. Aurora Limitless can make it easier to operate if you have a PostgreSQL application designed for database sharding.

The Engine is Aurora (PostgreSQL Compatible):

Not all PostgreSQL compatibility versions allow this option:

A Limitless database consists of multiple database instances. Some act as stateless query coordinators (called routers), and some are storage nodes (called shards) organized into a shard group. A minimum and maximum Aurora Capacity Unit (ACU) determines the system's capacity, influencing the number of routers and shards within the shard group.

An Aurora Limitless database cluster has only one shard group, which defines the compute instances (routers and shards). The cluster itself encompasses the storage ("Grover," the Aurora distributed storage servers).

Sharding alone does not ensure resilience. Regarding High Availability, it mitigates the impact of failures when they concern only one shard. However, the storage uses Aurora multi-AZ storage, which safeguards data. Additional standbys can be provisioned for faster failover and serving stale reads, and Aurora Limitless recovers the Two-Phase Commit pending transactions.

In the next few posts of this series, I'll explore how sharding works, its advantages, such as recharding and cross-node consistency, and its limitations in terms of performance and PostgreSQL compatibility.