Aurora gives me peace of mind and scales well. It's also the most expensive way to run Postgres I know, and the connection story for Lambda (RDS Proxy) is the part I like least.
Use it when
- The client is AWS-only, or needs IAM, VPC-only networking and AWS compliance.
- Bedrock Knowledge Bases with SQL access to the same chunks (Aurora is the only Postgres they support).
- Joining live tables with the data lake in one SQL query: the aurora_analytics extension (DuckDB inside, since 30 September 2026) reads Parquet and Iceberg in S3 as foreign tables, at no extra charge. Read-only, PostgreSQL 17.11+ or 18.6+.
Don't use it when
- New, small or spiky apps: Neon is cheaper and simpler.
Pricing
Serverless v2 kept at 0.5 ACU always-on ≈ $73 a month. RDS Proxy adds at least about $26 a month (provisioned) or about $146 (Serverless v2, minimum 8 ACU).
In my words: what hurts
- Very expensive.
- RDS Proxy is extra config, and its pools can still be exhausted.
Gotchas, with fixes
Gotcha: RDS Proxy 'pins' a session to one connection when it sees SET, prepared statements, temporary tables, advisory locks or statements over 16 KB. Pinned sessions exhaust the pool.
Fix: Watch the DatabaseConnectionsCurrentlySessionPinned metric and remove the pinning causes. Or move HTTP logic to Lambda Web Functions, which share one pool across up to 128 requests.
Gotcha: Serverless v2 can pause at 0 ACU, but resuming takes about 15 seconds (30+ after a day paused).
Fix: Don't pause production databases that serve users.
Provisioning
Official Pulumi package · Official Terraform provider
@pulumi/aws rds.Cluster / ClusterInstance.
Instead, consider
- Neon (serverless Postgres) Everything else.
Worked examples
Where it fits
- A database: Pick 02.
When the client must stay all-AWS.
- A data lake: Pick 05.
If the app already runs on Aurora: join live tables with the lake in one SQL query (DuckDB inside).
Sources
Last reviewed by Nicolas Dao