Database Scaling: Managed vs Self-Hosted, What Breaks First

Most teams don’t think about database scaling until something breaks. A query that used to take 50minutes now takes 3 seconds. The connection pool starts timing out at peak hours. The monthly bill jumps from $500 to $2,000 and nobody can explain exactly why.

At that point, the “managed vs self-hosted” question stops being theoretical. The real question becomes: what specifically is breaking, and is it because of the model you chose or would it break regardless?

In most cases, managed databases break first at system limits such as replica caps, single-writer bottlenecks, and storage constraints you can’t bypass. Self-hosted databases break first at operational complexity involving failover, backups, and scaling systems that your team has to build and maintain.

The right choice isn’t about which model scales further in theory. It’s about what fails earlier for your team, at your stage, with your resources.

The detailed comparison on managed vs self-hosted databases and which is better for your startup has already been covered in our previous article. This blog focuses specifically on database scaling managed vs self-hosted, the hard limits, the exact numbers, what breaks first in each model, and when it makes sense to switch.

We’ll cover real scaling limits from AWS RDS documentation, the operational challenges that actually break self-hosted setups, a stage-based framework for deciding when to move, and a third option that sits between managed and self-hosted that most teams don’t know about.

If your database is starting to feel slow, expensive, or constrained, this is the guide to read before making your next infrastructure decision.

How does database scaling managed vs self-hosted actually differ?

Database scaling managed vs self-hosted differs in one fundamental way: managed databases make scaling easy until you hit a ceiling that you can’t move. Self-hosted databases have no ceiling, but you’re the one building the ladder. The trade-off is convenience vs control, and it shows up the moment your database outgrows its first configuration.

There are two types of scaling, and they work differently depending on which model you’ve chosen.

Vertical scaling (making your machine bigger)

Think of it like moving from a small desk to a bigger one. More space, same room. Easy to do but the room has a maximum size.

• On managed (RDS): Click a button, pick a larger instance. Downtime may be required during the switch.
• On self-hosted: Resize your VM. Same process, but you pay raw compute pricing, no vendor markup on the bigger machine.

Horizontal scaling (adding more machines)

Think of it like adding more desks in more rooms. More total capacity, but now you need to coordinate between rooms.

• On managed (RDS): Add read replicas but you’re capped at 5 for RDS PostgreSQL, or 15 if you upgrade to Aurora. And writes still go through one machine only.
• On self-hosted: Add as many replicas as your infrastructure supports. Set up sharding if you need to distribute writes. But you build and maintain every connection between them yourself.

Managed vs Self-Hosted Database Scaling: Vertical vs Horizontal Comparison

Here’s how vertical and horizontal scaling differ across managed and self-hosted setups:

Model	Vertical (Scale Up)	Horizontal (Scale Out)
Managed	Easy (click a button. Ceiling exists)	Capped: 5 replicas (RDS PG), 15 (Aurora). Writes = single server only.
Self-hosted	Easy (resize your VM. No vendor markup)	Unlimited (but you build and maintain everything)

Most teams start with vertical scaling because it’s simple. The real differences between managed and self-hosted show up when vertical hits its ceiling and you need to go horizontal, that’s when managed starts imposing limits and self-hosted starts demanding expertise.

What does scaling architecture actually look like in each model?

So far, we’ve talked about scaling in theory, vertical vs horizontal. But what does it actually look like when you’re running a production system?

Managed (RDS / Aurora)

At a high level, most managed setups follow the same pattern:

• 1 primary database → handles all writes
• Up to 5–15 read replicas → handle read traffic
• Connection pooling layer → manages incoming connections

Everything is designed around a single-writer architecture. You can scale reads horizontally (to a point), but writes always go through one machine.

This works well until:

• Read traffic exceeds replica limits
• Write traffic becomes the bottleneck
• Failover events introduce lag or downtime

At that point, you’re not scaling anymore, you’re working around constraints.

If you’re already running into these trade-offs, it’s worth understanding the broader picture in our guide on managed vs self-hosted databases and which is better for your startup.

Self-hosted

Self-hosted architectures look similar at the start but diverge quickly as you scale:

• Primary + replicas → same as managed, but fully configurable
• Custom failover setup (Patroni, etc.) → you define how recovery works
• Load balancing layer → routes traffic across replicas
• Optional sharding layer → splits data across multiple databases

There’s no imposed ceiling, you can add replicas, introduce sharding, and separate workloads however you want.

But every component comes with responsibility:

• You configure failover
• You monitor replication lag
• You debug issues across multiple nodes

Scaling is no longer a button. It’s a system you build and maintain.
If you’re evaluating whether that trade-off makes sense for your team, the cost and operational breakdown in AWS RDS vs Self-Hosted PostgreSQL: Complete Cost Comparison helps put numbers behind it.

What this means in practice

Managed scaling gives you a pre-built architecture with limits.
Self-hosted gives you a flexible architecture with responsibility.

The moment you need to go beyond a single-writer system or want more control over how traffic is distributed, the difference becomes very real.

Quick comparison: scaling architecture

• Managed: Fixed architecture, pre-configured scaling, clear limits
• Self-hosted: Flexible architecture, no hard limits, but fully self-managed

In simple terms, managed gives you a system that works until it doesn’t. Self-hosted gives you a system that can scale indefinitely, if your team can keep up with it.

What are the hard limits of managed database scaling?

Managed databases like AWS RDS PostgreSQL have specific, documented limits: 64 TiB storage, 5 read replicas, single-writer architecture (meaning only one server handles all writes), and you cannot shrink storage once you increase it. These are hard limits, not soft guidelines. And when you hit them, the experience is painful.

AWS RDS PostgreSQL Scaling Limits (Real Numbers and Constraints)

Here are the actual scaling limits of AWS RDS PostgreSQL including storage, replicas, and performance constraints:

These aren’t edge cases. These are hard limits.

What Has a Limit	The Actual Limit	What It Means (Plain English)
Storage	64 TiB max (Aurora: 128 TiB)	Your database can’t grow past this. Period.
Read replicas	5 per source (Aurora: 15)	You can only spread read traffic across this many copies.
Largest instance	m8g.24xlarge — 768 GiB RAM	The biggest machine available. There’s nothing larger.
IOPS	256,000 max on io2 volumes	The maximum speed your storage can read/write data.
Connections	~5,000 before things slow down	Each connection uses 5–10 MB of memory. Past this, the database starts struggling.
Write scaling	Single-writer ONLY	All writes go through one machine. You cannot split writes across servers.
Storage shrinking	Impossible	If you increase storage, you’re paying for it forever — even after traffic drops.
Disk modifications	4 per 24 hours	You can only resize storage a few times per day — which can hurt during emergencies.