Keeping a database reachable at all times is one of the hardest problems for anyone running online services. A database is the ledger where an application keeps its data: orders, users, payments, catalogue. If it stops, everything stops. And when that same data has to be read and updated from different parts of the world at once, keeping it coherent becomes a puzzle. On 27 May 2025 AWS made Amazon Aurora DSQL generally available - meaning it left the restricted preview phase and opened to everyone - a database built for exactly this scenario.

What Aurora DSQL is

Aurora DSQL is a relational database: it organises data into tables of rows and columns that you query with SQL, the language used for this kind of store for decades. Two traits set it apart from a database installed on a traditional server.

It’s serverless. “Serverless” doesn’t mean there are no servers; it means the people using the service don’t have to choose, size, start or update them: AWS handles that behind the scenes. Developers just see an endpoint to connect to, and pay for the work the database actually does.

It’s distributed. The data doesn’t live on a single machine. It’s replicated automatically across several availability zones (nearby but independent data centres within a Region) and, if you want, across multiple geographic Regions.

A third detail matters to anyone already working with these tools: Aurora DSQL is PostgreSQL-compatible, PostgreSQL being one of the most widely used open source databases. The AWS documentation states compatibility with PostgreSQL version 16. In practice you connect with the same drivers, libraries and tools you already use with PostgreSQL, such as the psql client.

The problem it sets out to solve

Anyone who runs a traditional database knows the list of headaches by heart.

The first is maintenance. Applying security updates (patches) or moving to a new version often needs a window in which the database is slowed down or stopped. It has to be planned, announced and watched over.

The second is failover: what happens when the primary machine fails. In a classic setup a standby copy is ready to take over, but the switch has to be managed and is never entirely painless - there’s a stretch where the service struggles, downtime that has to stay under how long you can afford to be down, and in the worst cases you risk losing the most recent writes.

The third is growth. When data or traffic outgrows a single machine, the classic route is sharding: splitting the data into many pieces (shards) spread across several machines. It works, but it complicates everything. The application has to know which shard holds each record, and operations spanning more than one shard become slow and brittle.

Aurora DSQL is built to lift these three chores off developers’ shoulders: no manual patching, no failover to orchestrate, no sharding to design by hand.

High availability and strong consistency

These are two different promises, and it’s worth keeping them apart.

Availability measures how much of the time the service stays reachable. It’s usually expressed as a percentage. For Aurora DSQL, AWS states 99.99% availability in a single Region and 99.999% across multiple Regions. Put into concrete time: 99.99% means allowing at most roughly 52 minutes of downtime a year; 99.999% drops that to a little over 5 minutes a year. These are targets the provider states, not guarantees that nothing can ever go wrong, but they give a sense of the order of magnitude.

How does it get there? With an architecture AWS describes as active-active. Instead of one primary copy doing the work and a standby waiting, several copies work at the same time and can accept both reads and writes. If a component fails, traffic is rerouted automatically to healthy ones, without the traditional failover to coordinate. Each component is made redundant across three availability zones.

In the multi-Region setup, two clusters in two different Regions present themselves to the application as a single logical database: both endpoints accept reads and writes, a setup that also touches on GDPR compliance once data crosses several geographic areas. Acting as a referee is a third Region with a reduced role, called a log-only witness - it doesn’t serve requests but helps decide which version of the data is correct if something goes wrong.

Strong consistency is the second promise, and the more delicate one. In a distributed system, after a write the various copies of a record can take a moment to line up. Many systems accept this lag: it’s called eventual consistency, meaning “sooner or later all copies will match”. In the meantime, though, two users might read different values. Strong consistency instead promises that every read always sees the latest write, even one made from another Region. For a shopping cart, a balance or a booking, that distinction isn’t a detail: it’s the difference between selling the last item in stock twice or not. Aurora DSQL provides ACID transactions (the properties that make database operations reliable) with strong consistency, including across Regions.

Serverless: scaling without sharding or patching

The serverless side turns into two practical conveniences.

The first is automatic scaling. Aurora DSQL adjusts compute, read/write throughput and storage on its own, based on the load. If traffic doubles there’s no server to enlarge by hand and no sharding to redesign: this is usually the most time-consuming task, and here, on paper, it disappears.

The second is no maintenance on the user’s side. There are no servers to update, so there are no patching or upgrade windows to schedule, and none of the downtime that usually comes with them.

PostgreSQL-compatible, but with limits

Some honesty is needed here, because “compatible” doesn’t mean “identical”. Aurora DSQL speaks the PostgreSQL protocol and supports a broad slice of its features, but not all of them: AWS keeps a documentation page dedicated to what is and isn’t supported. Before assuming an existing PostgreSQL application will run unchanged, it’s worth checking that list.

There are also constraints on multi-Region use. At launch, multi-Region clusters could only be created among Regions in the same geographic grouping, and combinations across different continents weren’t supported. That’s a limit to factor in if the goal is serving users scattered across several continents from a single cluster.

Where it fits

Aurora DSQL is optimised for transactional workloads: many small, frequent operations - placing an order, updating a balance, recording a payment - where reliability and coherence are what count. AWS positions it for microservice, serverless and event-driven architectures, and mentions areas such as banking, ecommerce, travel, retail, multi-tenant SaaS, payments and gaming.

The opposite reasoning matters too, so as not to use it where it doesn’t help. It isn’t meant as a tool for analysing large volumes of historical data (so-called analytical or OLAP workloads), which follow different logic. And if an application needs a specific PostgreSQL feature that isn’t supported yet, or if a plain managed database in a single Region already covers the need, the complexity of a distributed database can be more than the job requires. The right choice depends on concrete availability and geographic-distribution requirements, not on the novelty itself.

Pricing, in brief

The cost model is pay-as-you-go. You pay for the work done through units called DPUs (Distributed Processing Units), which measure reads and writes, plus storage billed by GB-month. AWS includes a monthly free tier: the first 100,000 DPUs and 1 GB-month of storage each month are free. For real figures it’s best to start from the official pricing page anyway, because the total depends heavily on how the database is used, much like when you compare offers from different cloud providers.

Sources

• Amazon Aurora DSQL is now generally available (AWS News Blog)
• What is Amazon Aurora DSQL? (AWS Documentation)