---
title: Amazon Aurora DSQL
description: Aurora DSQL is the serverless distributed SQL database from AWS — Postgres-compatible, multi-region active-active, with strong consistency and unlimited horizontal scale.
url: https://www.factualminds.com/glossary/aurora-dsql/
publishDate: 2026-06-13
updateDate: 2026-06-13
---

# Amazon Aurora DSQL

> Aurora DSQL is the serverless distributed SQL database from AWS — Postgres-compatible, multi-region active-active, with strong consistency and unlimited horizontal scale.

## Definition

Amazon **Aurora DSQL** is a **serverless, distributed SQL** database announced at re:Invent 2024 and generally available in 2025–2026. It speaks the **PostgreSQL wire protocol** for many workloads, scales horizontally without application-level sharding, and supports **multi-region active-active** with strong consistency semantics aimed at global OLTP. DSQL targets problems solved elsewhere by Google Spanner or CockroachDB — inventory ledgers, global session state, financial records — while staying in the Aurora brand and AWS billing ecosystem.

Unlike single-region **Aurora**, DSQL has no manual failover, vacuum tuning, or writer instance sizing: you pay for **read and write request units** plus storage. Transactions use **optimistic concurrency** with snapshot isolation; conflicting commits return retriable errors your application must handle. DSQL is OLTP-first — not a warehouse, not a cache, and not a drop-in for every Postgres extension.

| Aspect      | Aurora (PostgreSQL)             | Aurora DSQL                |
| ----------- | ------------------------------- | -------------------------- |
| Topology    | Single-region writer + replicas | Multi-region active-active |
| Scaling     | Vertical + read replicas        | Horizontal, serverless     |
| Consistency | Strong in region                | Strong across regions      |
| Ops model   | Provisioned or Serverless v2    | Fully serverless           |

## When to use it

- **Global SaaS** needing one logical database with low-latency reads and writes in multiple AWS Regions.
- **Strong cross-region consistency** for ledgers, inventory, or entitlement state — not last-writer-wins NoSQL semantics.
- Teams that want **Postgres drivers and ORMs** without operating Patroni, Citus, or custom shard routers.
- Short OLTP transactions with idempotent retry logic already built into the app layer.

## When not to use it

- **Single-region** cost-sensitive OLTP — **Aurora Serverless v2** is simpler and usually cheaper.
- Long-running batch updates, **`COPY`-scale bulk loads**, or heavy stored procedures — DSQL optimizes for short transactions.
- Complex **PL/pgSQL**, exotic extensions, or full Postgres admin feature parity — validate support matrix before migration.
- Analytics dashboards — use Redshift, Athena on S3 Tables, or Aurora read analytics paths instead.

## Tips

- Implement **exponential backoff retry** on serialization failures as a standard middleware concern — not an edge case.
- Keep transactions **short and narrow** — wide multi-row locks increase conflict rates across regions.
- Model **idempotency keys** on writes so retries from mobile clients do not double-charge or duplicate rows.
- Use **regional endpoints** so apps talk to the nearest DSQL endpoint; understand how cross-region writes bill request units.
- Pilot with a **non-critical schema** (feature flags, session metadata) before moving financial core tables.

## Gotchas

- **Serious:** Treating DSQL like **single-region Aurora** — optimistic concurrency means commit-time failures are normal under load; apps must retry.
- **Serious:** **Multi-region active-active write amplification** — each write may incur replication cost in every linked region; FinOps surprises show up in request-unit lines, not instance hours.
- **Regular:** **Postgres compatibility is partial** — `LISTEN/NOTIFY`, some catalog queries, and admin commands differ; read the compatibility guide before lift-and-shift.
- **Regular:** **Connection storms** still hurt — use pooling discipline even though there are no instances to size.
- **Regular:** Migration cutover from Aurora requires **dual-write or DMS** planning — downtime windows depend on write volume and conflict handling.

## Official references

- [Aurora DSQL SQL reference](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/working-with-sql.html) — supported statements and limits.
- [Optimistic concurrency control](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/transactions.html) — retry patterns and isolation.

## Related FactualMinds content

- [Amazon Aurora](/glossary/amazon-aurora/) — single-region cloud-native relational
- [Amazon DynamoDB](/glossary/amazon-dynamodb/) — NoSQL multi-region alternative
- [AWS RDS Consulting](/services/aws-rds-consulting/)

## Related AWS Services

- aws-rds-consulting

---

*Source: https://www.factualminds.com/glossary/aurora-dsql/*