Managed or Self-Hosted? The Question I Ask Before Every Database

The debate is almost always framed as price. "RDS costs three times what an EC2 instance does" is true and largely irrelevant, because the thing you are actually buying or avoiding is operational ownership.

The question that decides it

Not "can we run this ourselves?" — nearly always yes. The question is: when this breaks in a way that is not in the runbook, who works the problem, and what is their daytime job?

If the answer is "a small platform team that already runs Kubernetes, has on-call, and has done failovers before," self-hosting is a real option. If the answer is "the application developers, who will be learning PostgreSQL recovery under pressure," buy the managed service and move on.

Every other consideration — cost, portability, control — is downstream of that.

What managed actually buys you

The provisioning is the least interesting part. What you are paying for is the absence of entire categories of work:

• Patch and version management. Security updates applied on a schedule you do not have to negotiate.
• Storage handling. Growth, IOPS, snapshots, and the failure modes of disks you never see.
• Failover mechanics. Multi-AZ promotion that has been tested by the provider millions of times, versus the first time you try it.
• Backups wired to the engine. Point-in-time recovery that is a checkbox rather than a cron job and a prayer.
• Scaling operations. Vertical resize with a maintenance window instead than a migration.

There is also a staffing truth: managed services are what make it plausible for four engineers to operate what would otherwise require a data specialist. That leverage is frequently worth more than the price delta.

Where the bill surprises people

Managed is not automatically more expensive, but it is priced differently. Costs that show up: the multiplier over raw compute, storage billed separately and often generously, cross-AZ data transfer inside the cluster, and read replicas that are full instance prices.

Where it wins is the tail. A node that fails at 04:00 costs managed nothing extra and costs you an engineer's night. Multiply that across a year and the raw instance comparison stops being the whole picture.

The honest accounting compares infrastructure plus the loaded cost of the people who would run it, not instance against instance.

When self-hosting is right

It is not just about saving money. Legitimate reasons:

Requirements the managed option does not meet. A specific extension, a storage engine, a tuning parameter, or a version the provider has not shipped yet. If the feature is load-bearing, there is no choice to make.

Cost at steady, predictable scale. A known, always-on workload with a capable team can undercut a managed offering, particularly on the storage side.

The data plane is your product. If you are a database company, or performance characteristics are the differentiator, running it yourself is the business, not a tax on it.

Portability as a genuine constraint. Sometimes multi-cloud is real — regulatory, contractual, or acquired-company real. Then avoiding provider-specific services matters enough to pay for it.

The bad reasons: a resume-driven desire to operate Cassandra, or assuming that because one engineer has run Postgres before, the team can.

The hybrid nobody mentions

The most common good outcome is neither pole. You can frequently take the provider's control plane and keep the data plane partly yours: a managed service with direct access for extensions, a managed Kafka with self-managed consumers, or the provider's backup orchestration over a database running on your own instances.

Equally common: managed for the databases that are boring infrastructure, self-hosted for the one where you have a specific reason. Splitting by workload beats applying a policy estate-wide — and it is the same right-sizing instinct, applied per service rather than per account.

Watch the lock-in worry

It is a real consideration and usually overweighted. A managed Postgres is still Postgres — a logical dump moves between providers, given time and a maintenance window. What does not port cheaply are the provider-specific extensions, the IAM integration, and the operational assumptions baked into your tooling.

Portability is a spectrum. Pay for it deliberately, at the layer that actually matters, rather than refusing every managed service as a matter of principle.

Summary

Start from who absorbs the failure, not from the invoice. Managed services buy you operational categories you do not have to staff, and that is worth paying for until you have the team and a specific reason not to. Self-host where requirements, steady scale, or product demands justify it — and expect the right answer to differ per workload rather than per company.