Managed vs Self-Hosted Databases on AWS: The Cost Comparison

For most small teams shipping their first production app, managed Postgres via RDS is the right default — you pay roughly $15-30/month for a db.t4g.micro and skip patching, backups, and failover engineering entirely. Self-hosting Postgres on a bare EC2 instance can shave a few dollars off the compute bill, but the savings evaporate the moment you value your own time or need a second person to sleep through an incident. DynamoDB and Aurora Serverless v2 change the math only under specific traffic shapes. This post lays out the concrete numbers for each option and the break-even points where switching is defensible.

The four options, priced honestly #

Start with the baseline. A single db.t4g.micro RDS Postgres instance with 20 GB of gp3 storage runs about $15-18/month on-demand, or closer to $10 with a one-year reserved commitment. Bump to db.t4g.small for a real workload and you’re near $30/month. Add a Multi-AZ standby for automatic failover and that roughly doubles — call it $60/month for t4g.small with high availability. Those are small-team numbers, and they buy you managed backups, minor-version patching, and a one-click restore that you did not have to build.

Self-hosted Postgres on EC2 is where the theoretical savings live. A t4g.small instance is about $12/month, plus an EBS volume, so you might land at $16-20/month all-in — cheaper than Multi-AZ RDS on paper. But that price excludes the labor: you own the backups, the point-in-time recovery, the OS patching, the Postgres upgrades, and the 3 a.m. page when the disk fills. We walk through that full tally in RDS vs Self-Hosted Postgres: The Real Cost for a Small Startup, and the honest conclusion is that self-hosting only wins once you have both scale and a person whose job is the database.

Aurora Serverless v2 is a different pricing model entirely: you pay per Aurora Capacity Unit (ACU) per hour, currently around $0.12/ACU-hour, with a configurable floor. If your minimum is 0.5 ACU, that’s roughly $43/month just to keep the lights on, before storage and I/O. It shines for spiky or unpredictable traffic where you’d otherwise over-provision, but for a steady low-traffic app it is frequently more expensive than a fixed t4g.small. The cost-truth breakdown lives in Aurora Serverless v2 vs Self-Managed RDS: The Startup Cost Truth.

DynamoDB is the outlier because it isn’t a relational database and shouldn’t be compared purely on price. On-demand mode charges per request — roughly $1.25 per million writes and $0.25 per million reads — plus $0.25/GB-month of storage. For a genuinely serverless, low-and-spiky access pattern, DynamoDB can cost pennies a month and scale to zero. For a read-heavy relational workload with joins and reporting queries, forcing it into DynamoDB trades a small AWS bill for a large engineering one.

Where the break-even points actually are #

The decision is rarely about the raw dollar figure — the spread between the cheapest and most expensive option here is maybe $50/month at small scale, which is noise next to an engineer’s hourly rate. The real break-evens are about operational load.

• RDS single-AZ when downtime during a reboot is acceptable and you want zero DBA overhead.
• Multi-AZ RDS when a few minutes of downtime costs you customers.
• Aurora Serverless v2 when your traffic swings by 5-10x and you’re currently paying for peak capacity you rarely use.
• DynamoDB only when your access pattern is key-value or single-table by nature, not when you’re trying to save $20.

Self-hosting deserves its own rule: don’t, until you’ve measured a real bottleneck that managed services can’t address, and you have someone accountable for the database on-call rotation. The related guidance in When to Stop Using AWS Managed Services and Self-Manage holds here — the crossover is a function of headcount and predictability, not instance pricing. Notice that none of these break-evens hinge on the sticker price; they hinge on how much a failure costs you and who is around to fix it.

How Vylara picks — and lets you override #

When you connect the Vylara GitHub App and the agent engine analyzes your repository, it detects your database from your dependencies. A prisma, typeorm, pg, or psycopg2 import surfaces PostgreSQL; @aws-sdk/client-dynamodb or a DYNAMODB_TABLE_NAME env var surfaces DynamoDB. On the "Your app needs" screen you see a plain card — PostgreSQL Database, detected via prisma, ~$15/mo — with two choices: create a managed database for me, or I already have one and paste a connection string. You are not staring at instance classes or capacity units; you’re making a cost-shaped product decision.

Everything provisions into your own AWS account. Vylara never hosts your data — the RDS instance, the DynamoDB table, the storage bucket all live under your account, and billing flows straight from AWS to you. Vylara charges for the orchestration layer, not the compute. The database is created on your first deploy, not when a PR merges; merging only updates your repo with the generated Dockerfile, CI pipeline, and deployment configs. After the environment is live, the connection URL is persisted under cloud_config.service and shown in your dashboard.

{
  "service": {
    "primary_url": "myapp.internal:5432",
    "notes": "managed PostgreSQL, db.t4g.micro"
  }
}

Be honest about the limit here: the initial sizing is an educated guess. The agent reads your dependencies, not your production traffic, so it defaults to a conservative, low-cost tier. That’s a feature for cost control — it errs toward the $15/month instance rather than an oversized one — but it means you should treat the first choice as a starting point. Once metrics come in, the platform surfaces scale-up-under-load and scale-down-to-save suggestions as one-click actions, and you can ask the in-app infrastructure chat why a database is sized the way it is. Any change that modifies infrastructure still requires your explicit approval before it applies.

If you want the broader picture of how these database choices fit into a full AWS deployment — networking, load balancing, secrets — start from the AWS deployment guide. The database is usually the highest-stakes line item on the bill, but it’s rarely the most expensive when you get the sizing right, and moving from a wrong choice to a right one costs far more in engineering time than the monthly difference ever will.