Harnessing AWS Aurora DSQL: Deploying Serverless, Globally Distributed SQL Databases with Terraform
Introducing Amazon Aurora DSQL
Amazon Aurora DSQL is a serverless, distributed SQL database engineered for high availability, strong consistency, and unlimited scalability — all without manual provisioning or database sharding. General availability was announced on May 27, 2025.
Key Highlights
- Serverless architecture: Fully managed — no provisioning, patching, or downtime during maintenance.
- Active‑active distributed architecture: Designed for 99.99% single‑Region and 99.999% multi‑Region availability, with no single point of failure.
- PostgreSQL‑compatible: Get started with familiar SQL syntax, tools, drivers, ORMs — all compatible with PostgreSQL 16 subset.
- Strong consistency across Regions: Applications can read and write to any regional endpoint while seeing the same data everywhere.
- 4× faster reads and writes compared to other distributed SQL systems, achieved via decoupled transaction processing and globally synchronised time using Amazon Time Sync Service.
Aurora DSQL removes operational complexity from global transactional workloads, it is ideal for real‑time financial systems, leaderboards, social networks, microservices, SaaS platforms, and more.
Understanding AWS Aurora DSQL Limitations
While Aurora DSQL delivers groundbreaking scalability, strong consistency, and ease of management, it’s essential to consider certain limitations:
1. Limited PostgreSQL Compatibility
Aurora DSQL currently supports only a subset of PostgreSQL 16 features. Some advanced PostgreSQL extensions, functions, or custom types may not yet be fully supported. Evaluate your application’s reliance on specific PostgreSQL features before migrating.
Currently unsupported features are listed here.
2. Region and Availability Constraints
Although AWS is rapidly expanding Aurora DSQL’s availability, it’s initially restricted to select regions. This constraint may impact latency-sensitive applications or those bound by regional data-residency regulations.
3. Serverless Scaling Latency
Aurora DSQL’s serverless architecture provides automated scaling; however, there might be brief latency spikes during sudden, extreme scaling events. Applications with strict performance SLAs should proactively manage and anticipate potential scale-up events.
4. Cost Considerations
Due to its globally distributed and always-on replication nature, Aurora DSQL can be more expensive compared to traditional single-region databases. It’s crucial to analyse cost implications for workloads with substantial global transaction volumes.
5. Backup and Restore Flexibility
Automated backups and point-in-time restores are supported but may have limitations regarding flexibility across multi-region clusters. Consider disaster recovery strategies carefully and test backup and restore processes regularly.
Deploying Aurora DSQL with Terraform
### DSQL cluster
resource "aws_dsql_cluster" "main" {
deletion_protection_enabled = true
kms_encryption_key = module.main.key_arn
tags = {
Name = "dsql main cluster"
}
}
### VPCE for dsql
resource "aws_vpc_endpoint" "main" {
vpc_id = data.aws_vpc.main.id
service_name = aws_dsql_cluster.main.vpc_endpoint_service_name
vpc_endpoint_type = "Interface"
security_group_ids = [
aws_security_group.main.id,
]
private_dns_enabled = true
}
resource "aws_security_group" "main" {
name = "dsql-main-sg"
description = "VPC endpoint DSQL security group"
vpc_id = data.aws_vpc.main.id
}
resource "aws_vpc_security_group_ingress_rule" "main_inbound_postgres" {
security_group_id = aws_security_group.main.id
cidr_ipv4 = data.aws_vpc.main.cidr_block
from_port = 5432
ip_protocol = "tcp"
to_port = 5432
}
resource "aws_vpc_security_group_egress_rule" "main_outbound" {
security_group_id = aws_security_group.main.id
cidr_ipv4 = "0.0.0.0/0"
ip_protocol = "-1" # semantically equivalent to all ports
}
### VPC data and policies
data "aws_vpc" "main" {
id = "vpc-1234566789"
}
data "aws_iam_policy_document" "kms_core" {
statement {
sid = "AllowKeyUseServiceDSQL"
actions = [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:DescribeKey"
]
principals {
type = "Service"
identifiers = [
"dsql.amazonaws.com"
]
}
resources = ["*"]
}
}
### KMS
module "kms_core" {
source = "native-cube/kms/aws"
version = "~> 1.0.0"
alias_name = "core-kms-key"
policy = data.aws_iam_policy_document.kms_core.json
}More on using VPC Endpoints for your DSQL cluster can be found in the official docs.
IAM Role configuration to access DSQL cluster
In my case I am using IAM Roles for service account feature and the following is configured:
resource "aws_iam_role" "dsql_cluster_admin" {
name = "dsql-cluster-admin"
assume_role_policy = data.aws_iam_policy_document.dsql_cluster_admin_assume_role.json
}
resource "aws_iam_role_policy" "dsql_cluster_admin" {
name = "dsql-cluster-admin-perms"
role = aws_iam_role.dsql_cluster_admin.id
policy = data.aws_iam_policy_document.dsql_cluster_admin_role.json
}
data "aws_iam_policy_document" "dsql_cluster_admin_assume_role" {
statement {
sid = "ConfigureOIDCRole"
effect = "Allow"
actions = [
"sts:AssumeRoleWithWebIdentity"
]
principals {
type = "Federated"
identifiers = [local.eks_oidc_arn] # this will be difference for your eks setup
}
condition {
test = "StringEquals"
variable = local.eks_oidc_url # this will be difference for your eks setup
values = ["system:serviceaccount:NAMESPACE_NAME:K8S_SA_NAME"]
}
}
}
data "aws_iam_policy_document" "dsql_cluster_admin_role" {
statement {
effect = "Allow"
actions = [
"dsql:GetCluster",
"dsql:ListClusters"
]
resources = [
aws_dsql_cluster.main.arn
]
}
statement {
effect = "Allow"
actions = [
"dsql:DbConnectAdmin"
]
resources = [
aws_dsql_cluster.main.arn
]
}
}Finally connecting to DSQL cluster. Official instructions are available here. However, I went on to use DBeaver. Note, that you don’t need a paid version as AWS AUTH doesn’t work yet with DBeaver version so you need to use temporary creds which are very short lived.
DBeaver is an open-source, GUI-based database tool. To download DBeaver, see the download page on the DBeaver Community website. The following steps explain how to connect to your cluster using DBeaver.
To set up a new Aurora DSQL connection in DBeaver
- Choose New Database Connection.
- In the New Database Connection window, choose PostgreSQL.
- In the Connection settings/Main tab, choose Connect by: Host and enter the following information.
- Host — Use your cluster endpoint.
- Database — Enter
postgres - Authentication — Choose
Database Native - Username — Enter
admin - Password — Generate an authentication token. Copy the generated token and use it as your password.
- Ignore any warnings and paste your authentication token into the DBeaver Password field.
- You must set SSL mode in the client connections. Aurora DSQL supports
SSLMODE=require. Aurora DSQL enforces SSL communication on the server side and rejects non-SSL connections.
Final Thoughts
Amazon Aurora DSQL achieves what many single-region or sharded systems struggle with: scalable, distributed SQL with strong consistency and minimal operational overhead. With AWS reaching general availability on May 27, 2025, DSQL is ready for real-world production use across multiple regions.
Using Terraform and the scripts I provided above, you can automate the entire deployment of both single-region and multi-region globally consistent clusters. This dramatically speeds up deployment, standardises architecture, and helps ensure reliability from day one.
Please bare in mind a lot of limitations it currently has which I listed as well. Accessing Aurora DSQL with UI also isn’t ideal and most common tools such as PGAdmin is not working with it. Additionally, local development with DSQL is rather difficult.
Last note, if you are using GOLang to implement your backend to connect to Aurora DSQL then consider following issue as well!
Decision is yours. Enjoy!
