Vendor lock-in in managed databases: how to keep an exit door open
Nobody signs a lock-in clause. There isn't one. You will not find a paragraph in any database contract that says "you can never leave."
And yet I regularly meet companies that are, for all practical purposes, prisoners of their database provider. Unhappy with the service, unhappy with the price, and staying anyway.
So where does the lock come from, if it's not in the contract?
It's in the architecture.
And the good news is: architecture is a choice.
The three quiet locks
Lock one: the exit toll.
Data is free to enter almost every platform and metered on the way out. That sounds harmless when you have 200 gigabytes. At 20 terabytes, the price of moving your own data out is a number that makes the CFO sit down: egress at $0.09-0.12/GB is negligible until you are moving 10-15 TB, at which point it adds four figures a month. And it grows every month, automatically, because your data grows. Nobody built a wall. The wall built itself.
Lock two: the proprietary comfort features.
The platform's search add-on. The dashboard product. The convenient API that only exists there. Each one saved your team two weeks when you adopted it. Each one costs a re-architecture project when you leave. Convenience is how modern lock-in gets installed: one helpful feature at a time.
Lock three: the knowledge gap.
After a few years with a provider, they know things about your environment that your own team doesn't. Which settings were changed and why. Where the bodies are buried. If all of that lives in their heads and their ticketing system, then switching means starting your operational memory from zero. That fear keeps more companies stuck than any invoice.
The test I give
Ask your provider, in writing: "What does it cost, and how long does it take, to move 100% of our data and operations away from you, today?"
Every provider sends you a meeting invite and you will see how they react.
How to build databases you can walk away from
When your provider knows you can leave, you get their best behavior. When they know you can't, you get only their invoice. There are four choices to keep the door open:
Run on open-source engines.
PostgreSQL, MySQL, Apache Cassandra, MongoDB, Redis, Kafka, Elasticsearch. This is not a fringe bet: PostgreSQL is the most-used database among developers and MySQL is close behind, so the skills are everywhere, the tooling is portable, and no single company controls your runtime. A proprietary engine can still be the right call for a specific job, but make it a conscious trade, not a default.
Run in your own cloud accounts.
If the databases live in your infrastructure, "leaving your provider" means changing who operates them, not moving the data at all. The exit toll drops to roughly zero, because there's no boundary to cross. This is the single most powerful anti-lock-in decision available, and almost nobody asks for it.
Demand documentation as a deliverable.
Runbooks, architecture decisions, change history: in your systems, not theirs, updated as part of the service. The knowledge gap is a choice too.
Put the exit in the contract on day one.
Offboarding support, knowledge transfer, data handover formats, and the price of all of it, agreed while everyone still likes each other. Negotiating an exit during an exit is not negotiating.
Where we stand
I'll be transparent about our angle, because it would be strange not to be.
Maxima Consulting built its managed database service on exactly these principles: open-source-based stack (PostgreSQL, MySQL, Cassandra, and more), deployed in the client's own cloud accounts, documentation in the client's systems, 24/7/365 follow-the-sun SRE operations under a 99.99% uptime SLA.
The platform underneath, Cloud Orbit, is itself built on industry-standard open-source tooling, on purpose.
Why would a provider design a service that's easy to leave? Because it's the strongest retention strategy there is. Every client who stays with us chooses it. A decade-long client relationship built on an open door says more than any lock ever could.
FAQ
What is vendor lock-in in managed databases?
The practical inability to switch providers at reasonable cost, created not by contracts but by architecture: egress fees that scale with data volume, proprietary features requiring re-architecture, and operational knowledge held only by the provider.
How do I avoid lock-in with a database provider?
Four moves: open-source engines, deployment in your own cloud accounts, documentation delivered into your systems as part of the service, and offboarding terms agreed in the original contract.
Is open source enough to prevent lock-in?
No. Open-source engines running on a provider's platform still leave you paying the exit toll on your data. Open source plus your own accounts is the combination that keeps the exit near zero.
Does avoiding lock-in cost more?
It can cost some convenience upfront: platform add-ons are genuinely handy. Over the life of the estate, the leverage usually pays for itself, because a provider you can leave prices and behaves like a provider you can leave.
