A managed database vendor changed its pricing model again and called it 'simplification'

A managed database vendor rolled out a new pricing tier structure this week, announced under a blog post titled, I am not kidding, “Simplifying pricing for our customers.” Read the actual change: they collapsed four billing dimensions into two, and the two that remain both scale worse for the exact workload profile most of their mid-market customers run.

I’ve been doing this long enough to have a Pavlovian response to the word “simplify” in a pricing announcement. It has never once, in my experience, meant the bill goes down. It means the bill becomes harder to predict in a direction that favors the vendor, wrapped in language that makes complaining about it feel like you’re the one who doesn’t get it.

The actual pattern, every time

1. Usage-based pricing launches generous, because generous pricing is how you win the initial adoption. Nobody churns off a database at month three over pricing.
2. Once migration cost is sufficiently painful (and for a database, it’s always sufficiently painful, that’s the whole reason you picked a managed one), the pricing model “simplifies.”
3. The new model is announced with a calculator that makes your specific workload look fine, because the calculator’s default assumptions never match your specific workload.
4. Six months later finance asks why the database line item doubled and nobody remembers agreeing to that.

This isn’t a conspiracy, it’s just how lock-in economics work once the switching cost is real. You don’t need bad faith from the vendor, you just need customers who can’t easily leave, and a database is the single hardest thing in most stacks to easily leave.

What actually protects you

Not “avoid managed databases,” they solve real problems and I use several. What protects you is knowing your exit cost before you need it, not discovering it during a pricing dispute:

• Keep a documented, tested path to export your full dataset in a portable format. Test it quarterly, not “whenever we get around to it.”
• Track your actual usage against the vendor’s billing dimensions yourself, independently, so a pricing change is a five-minute recalculation instead of a fire drill.
• Read every pricing announcement assuming it’s adversarial until proven otherwise. Not because the vendor is evil, but because “simplification” is doing a lot of load-bearing work in that sentence, and load-bearing words deserve scrutiny.

Every vendor eventually optimizes for the customers who can’t leave over the customers who can. The only defense is staying in the second group.

What I actually track to stay portable

“Keep a documented exit path” is correct and also sounds abstract until you’re in a pricing argument. Here is what concrete looks like in practice.

For any managed database that holds data you couldn’t reconstruct from scratch, I keep a runbook entry with three numbers: current row count (updated by a weekly cron), estimated full dump size in GB, and the last time I actually ran a test restore from a dump into a clean instance. That last one is the one that expires. Schema drift, format changes, and dependency version mismatches accumulate quietly, and “we have backups” is not the same as “we can restore.” If the test restore is more than 90 days old, the exit path is theoretical.

The portable format question matters more than most people think. If your only export path is a vendor-specific dump format that requires their tooling to restore, you have a softer version of the same lock-in problem. PostgreSQL dump to standard SQL, or direct COPY TO to CSV for anything you might want to migrate, is the difference between a week-long migration project and a six-month one.

The egress fee angle compounds this: the same vendor class that reprices writes usually also charges for data egress at rates that make test restores feel expensive. If you’re discouraging yourself from testing the exit path because the egress bill is annoying, that’s the lock-in working as designed. Budget the egress cost into your quarterly restore test and treat it as insurance. Compare it to the egress fees post from last week, which covers the network side of the same pattern.

The temporary NFS mount tale is, structurally, the same problem: a dependency that was supposed to be provisional became load-bearing before anyone noticed. Same pattern, different layer of the stack.