Vendor Lock-In Isn't the Risk. Pretending You Can Avoid It Is.
Vendor lock-in has a reputation as the cardinal sin of infrastructure decisions - the thing every architecture review warns against, the reason teams write their own abstraction layer over a cloud provider's managed database before they've even validated the product. It's treated as an unqualified risk to be engineered away from the start.
It isn't. Lock-in is a cost, like every other infrastructure decision has a cost. The mistake isn't accepting it - the mistake is pretending you can build your way out of paying it.
The Abstraction Layer Doesn't Remove the Cost. It Hides It.
The standard defense against lock-in is a portability layer: an internal interface that wraps the cloud provider's service, so that in theory, swapping providers means rewriting the wrapper instead of the application. It sounds like insurance. In practice, it's a tax paid on every single feature, forever, to hedge against a migration that - for most teams never happens.
Worse, the abstraction layer usually can't actually deliver what it promises. A generic interface over a managed Postgres and a generic interface over DynamoDB necessarily flattens both down to their lowest common feature set, which means you've paid the engineering cost of abstraction and still lose the specific capabilities the specific consistency guarantees, the specific scaling behavior that made either provider worth choosing in the first place. You get the cost of portability without the benefit of it.
The Question That Actually Matters
If we had to migrate off this provider in eighteen months, what would that actually cost and is that cost lower than what we'd spend hedging against it for eighteen months first?
For most early and growth-stage products, the honest answer is that the hedge costs more than the migration would, because the migration is a hypothetical that may never materialize, while the hedge is a real, ongoing cost paid on every feature shipped in the meantime.
What Changes Once Lock-In Is Priced, Not Feared
Use the managed service's actual capabilities. If a provider's specific queueing, caching, or auth primitives solve a real problem well, use them directly instead of routing through a generic wrapper that can't express what makes them useful. The speed and reliability gained now is worth more than optionality you may never exercise.
Design the exit at the data layer, not the application layer. The part of a migration that's genuinely expensive is usually data schema, format, volume not application logic. Keeping data in portable formats and avoiding proprietary lock-in specifically at the storage layer captures most of the real migration risk, without the tax of abstracting every service.
Treat lock-in risk as a function of switching cost times probability of switching, not as a binary to be avoided. A startup two years from product-market fit has a low probability of a provider migration being the right move at all the business risk of not shipping fast enough dwarfs the infrastructure risk of being tied to one vendor.
Where This Reverses
This isn't a blanket argument for maximal lock-in. Once a system has scale, revenue, and a multi-year horizon, the probability side of that equation changes, and so does the right answer a large, mature platform re-evaluating a genuinely painful provider relationship is making a very different trade-off than an 18-month-old startup hedging against a migration it may never need. The mistake is applying the mature-company answer at the startup stage, where the abstraction tax gets paid for years before the flexibility it bought ever gets used.
The Decision, Not the Wrapper
None of this requires picking a provider and never questioning it again. What it requires is being honest that portability has a cost, pricing that cost against the actual probability you'll need it, and choosing deliberately instead of defaulting to an abstraction layer because avoiding lock-in feels like the responsible answer.
Get that trade-off right, and vendor choice becomes a straightforward decision made on its merits. Get it wrong, and you've spent years paying for an exit you were never going to take.
// keep going
Want this kind of thinking applied to your stack?
An appraisal is the fastest way to find out where your architecture is quietly costing you.