A two-person startup runs its production Postgres itself on a small virtual machine - about 25 dollars a month against roughly 120 dollars for the managed equivalent. What is the team actually buying with the 95 dollars it saves each month?

What is being tested

Whether you can price a saving in the same currency as what it buys. 1100 dollars a year is about half a working day of one engineer's fully loaded time per month - so the decision turns entirely on whether self-managing costs less than half a day a month. It does not.

The mechanism

A managed database does not remove database work. It removes a specific list of tasks that are easy to defer and expensive to get wrong: scheduled backups with point-in-time recovery, restore tooling that someone else tests, failover to a standby, minor-version patching, and the mechanics of a major-version upgrade. What it leaves entirely with you is schema design, indexing, query tuning, connection limits and capacity.

The failure mode is not "the VM goes down". It is the first restore. A backup is a hypothesis until it has been restored into a running system with a measured recovery time. Teams this size typically have a cron job writing dumps to object storage, no restore drill, and a recovery point objective that is whatever the last successful dump was - often 24 hours, sometimes weeks of silent failure because nothing checks that the dump is non-empty.

Why the other options fail

• Lower latency from sharing a host. A real effect and the wrong size. A same-host socket saves perhaps a millisecond over a same-zone network hop, which matters for a 2-millisecond query at thousands of requests a second and is invisible at this scale. If latency were the reason, you would measure it first - and you would find the query plan, not the hop.
• Freedom from the provider's version schedule. This is a genuine reason to self-manage and it is the wrong one here, because it only pays once you have a version-pinned dependency - an extension the provider does not offer, or a certification that forbids an unplanned upgrade. A two-person team with a stock schema has nothing pinned, and gains only the duty to patch.
• The costs are about the same. They are not: the ratio really is about 5x on the infrastructure line. Pretending the difference away loses the actual argument, which is that the line is small in absolute terms - 95 dollars a month - so it should not drive an architectural choice at all.

The decision rule

Default to managed while the managed bill is smaller than the fully loaded cost of the engineering time it replaces. Concretely: below roughly 500 dollars a month of managed spend, self-managing almost never pays, because the smallest plausible operational commitment - patching, monitoring and one restore drill a quarter - is already worth more than the saving.

It flips on two things, not on price: when managed spend grows past roughly 20-30% of an engineer's cost and the workload is stable enough that self-managing is a known quantity, or when a hard constraint appears - data residency, an unsupported extension, a version you must hold.

When this is the wrong answer

For a database nobody's money depends on, self-host freely. A development instance, a scratch analytics copy, a staging environment: the restore story is "recreate it", so the saving is real and the risk is zero. The distinction is not the technology - it is whether a lost hour of writes is an inconvenience or an incident.