Aurora Serverless v2 vs Self-Managed RDS: The Startup Cost Truth

For a typical early-stage startup with steady, low traffic, a small self-managed RDS instance is cheaper than Aurora Serverless v2 — often by 2-4x. Aurora Serverless only wins when your load is genuinely spiky or unpredictable, because you pay for capacity by the second instead of renting a fixed box. The decision comes down to one question: does your database sit mostly idle with occasional bursts, or does it run a consistent baseline all day? Get that answer wrong and you either overpay for elasticity you don’t use, or you fight capacity limits you could have avoided.

This post walks the real numbers for a small team, then explains where each option actually earns its keep. For the broader picture of running databases on AWS, see our AWS guides. If you want the plain Postgres-on-AWS comparison first, we covered it in RDS vs self-hosted Postgres: the real cost for a small startup — this one is specifically about the serverless-versus-provisioned axis inside RDS itself.

The pricing models are fundamentally different #

Self-managed RDS (a provisioned instance) bills you a fixed hourly rate for a fixed machine, whether it’s slammed or idle. A db.t4g.small (2 vCPU burstable, 2 GiB RAM) runs roughly $0.032/hour in us-east-1, about $23/month on-demand, before storage. Add 20 GB of gp3 storage at ~$0.115/GB-month and you’re near $26/month for a single-AZ instance. That’s your database, flat, all month, no surprises.

Aurora Serverless v2 bills by Aurora Capacity Units (ACUs), measured per second. One ACU is roughly 2 GiB of RAM plus associated CPU and networking, and it costs about $0.12 per ACU-hour in us-east-1. The minimum you can set today is 0.5 ACU, so even a database doing nothing floors at roughly $0.06/hour, about $43/month just to stay awake. Storage and I/O are billed separately. So the floor of Aurora Serverless already sits meaningfully above the all-in cost of a small provisioned instance.

When self-managed RDS is the cheaper choice #

If your app serves a few thousand requests a day with a predictable baseline — the profile of most pre-product-market-fit startups — a db.t4g.small or db.t4g.medium handles it comfortably for $23-$60/month. Aurora Serverless at its 0.5-ACU floor already costs more, and any sustained load pushes it higher. For steady, modest workloads, the elasticity is a premium you pay for and never use. This is the same logic behind your infra should cost $180/mo until it deserves $680/mo: match the spend to the actual shape of the load, not to the load you hope to have.

There’s an operational cost too, but it’s smaller than people assume. RDS is a managed service — AWS handles patching, backups, and failover for you. "Self-managed" here means you pick the instance size and manage connection limits, not that you’re running Postgres on a raw EC2 box. A t4g.small gives you around 170 max connections, which is plenty for a small app, though you’ll want pooling before you get close; we go deep on that in RDS connection pooling for a small app.

When Aurora Serverless v2 earns its price #

Aurora Serverless is worth it when your load is genuinely uneven. Think a B2B tool that’s dead on weekends, a batch pipeline that spikes for two hours a night, or a demo environment used only during business hours. In those cases you pay for near-zero capacity most of the time and scale up only when work arrives — and because ACUs adjust in fine-grained steps, you don’t over-provision for the peak. If your traffic swings from 0.5 ACU to 8 ACU for a few hours a day, the average bill can land below a provisioned instance sized for that same peak.

The other real advantage is not having to guess an instance size before you know your traffic. Provisioned RDS forces a sizing decision up front; Aurora Serverless lets the ceiling ride the workload. If your growth is lumpy and unpredictable, that removes a class of migration events — you set a max ACU and let it breathe. The trade-off is that scale-up is not instantaneous, and bursts after a quiet period can see brief latency while capacity ramps, so it’s not a free lunch for latency-sensitive spikes.

How Vylara sizes this for you #

When you connect a repository through the Vylara GitHub App, the Vylara agent scans your dependencies and detects that you need a database — spotting prisma, pg, typeorm, or similar in your package.json. On the "Your App Needs" screen it offers a managed PostgreSQL database (shown at roughly ~$15/mo for a small managed instance) or lets you point at one you already own. Nothing is provisioned until you approve and run the first deploy, which creates the database in your own AWS account via a blue/green rollout. You keep the billing relationship with AWS directly; Vylara charges for the orchestration layer, not for the compute or storage.

Because the resources live in your account, the sizing decision stays yours to revisit. After launch, the in-app infrastructure chat can read your database metrics and cost data and suggest scaling down when you’re overprovisioned or up under load — with a one-click action you confirm before anything changes. That’s the honest workflow: the agent proposes, you approve, and the number on your AWS bill is one you saw coming.

Whatever you pick, keep one habit: the sizing is a guess until real traffic pins it down. Start on a small provisioned instance if your load looks steady, watch the CloudWatch CPU and connection metrics for a couple of weeks, and reach for Aurora Serverless only when you can point at genuine spikiness in the data. Elasticity you can measure is worth paying for; elasticity you’re imagining is just a markup.