AWS Aurora DSQL Looked Perfect Until I Needed the Connection String

The Setup

I'm building AI chat features for my blog. I wanted Postgres because it's my go-to database. I decided to try the AWS stack since we use it at work.

I always use RDS at work but figured I'd try something new. Aurora DSQL caught my attention—serverless Postgres with distributed SQL. The pricing looked good for low-traffic personal projects. Way better than Aurora Serverless v2, which is AWS's special type of "Serverless"—it isn't serverless and doesn't spin down to zero.

I did my homework. Read through the unsupported features list. Foreign keys? Don't need them. PostGIS and PGVector? Not for this project. 3,000 row transaction limit? My chat features won't hit that.

Nothing on that list was a dealbreaker.

The Deployment

Created a CloudFormation template. Had to update SAM CLI first, and there were issues, of course. A few small issues later, deployment succeeded. Resource created, endpoint ready.

Check this git commit for infra code: infra/cloudformation/dsql.yaml

Time to grab the connection string and wire it into my Cloudflare Worker.

That's when I saw it.

The Discovery

No username field. No password field. Just: "Use IAM authentication."

AWS Aurora DSQL doesn't support traditional username/password authentication. Period.

Just IAM authentication with temporary tokens that expire every 15 minutes.

Here's how it works:

1. Create an IAM role with database permissions
2. Generate a temporary token (15-minute expiration)
3. Use the token as password
4. When the connection drops after 15 minutes, generate a new token

The Problem

This immediately killed it for my use case.

Cloudflare Workers are serverless edge functions. Short-lived, stateless, potentially spanning minutes between invocations. The entire model assumes connection pooling or connection-per-request patterns with credentials that don't expire mid-session.

The 15-minute token expiration means:

• Can't use standard connection pooling (pool outlives token)
• Can't cache tokens between worker invocations reliably
• Need AWS SDK running in every worker to generate tokens
• Additional cold start latency for token generation
• More complexity for credential management

Could I have made it work? Probably. Generate token on each invocation, accept the latency, handle token refresh logic.

But at that point—why?

The Missing Context

The unsupported features list told me about foreign keys and triggers. It mentioned the 3,000 row transaction limit and one-hour connection timeout.

What it didn't mention up front: "This database requires IAM authentication. No username/password support."

That's not a missing Postgres feature. That's a fundamental authentication model that changes how you architect your application.

Gee, AWS, I wonder why everyone uses Supabase or Neon for serverless Postgres these days? It's like you got so close, then just blew it at the last second.