The Vendor Lock-In Checklist for Your Vector Search Stack
Vendor lock-in in a RAG stack rarely shows up as a single decision. It builds up from a dozen small choices, a proprietary index format here, a vendor-specific reranking API there, until switching costs more than staying, even when staying is clearly the worse option.
The way to avoid ending up there isn't picking a single vendor marketed as open and calling it done. It's checking, layer by layer, what actually locks you in and what doesn't.
Your embeddings are more portable than your index
The vectors your embedding model produces are just arrays of floats; you can export them and load them into almost any vector database. What's much harder to move is the index itself, the graph or tree structure a vector database builds on top of those floats to make search fast. If your provider doesn't let you export raw vectors alongside your source documents, you're not locked into an index format, you're locked into never being able to rebuild one elsewhere without re-embedding everything from scratch. Say a document is chunked into six passages before embedding: exporting your data has to mean all six vectors per document plus which document and passage each one maps back to, not just the original source file.
Check what a full re-embed would actually cost you
Every vendor migration for a vector search system eventually requires the same worst case: re-embedding your entire corpus with whatever model you're moving to. Work out that cost before you need it, not during an outage or a pricing change. If your corpus is large and re-embedding would take weeks of inference time, that lead time is your real switching cost, more than any contract term. This number changes over time too: your corpus grows, so the re-embed cost you calculate today should be revisited alongside your regular capacity planning, not treated as fixed.
Watch for lock-in in the retrieval logic, not just the database
Reranking, hybrid search that blends keyword and vector scores, and metadata filtering often live behind vendor-specific APIs that don't have a direct equivalent elsewhere. If your application code calls a proprietary reranking endpoint directly, moving vector databases means rebuilding that logic too, not just pointing at a new connection string. Keep this layer abstracted behind your own interface so a vendor swap touches one adapter, not every place in your codebase that calls the search API.
For example, an application calls a vendor's reranking endpoint directly from a dozen request handlers. When pricing changes and the team wants to move, every handler has to be found, rewritten, and retested, on top of migrating the data. If those calls had gone through one interface owned by the team, the swap would touch a single adapter and the reranking behavior could be verified in one place. The extra layer costs a little latency and engineering time, which is why it's worth building only where the switching cost is highest.
A portability checklist to run before you commit
- Can you export raw vectors and source document references, not just query results?
- What's the estimated time and cost to re-embed your full corpus with a different provider?
- Is reranking or hybrid search logic abstracted behind your own interface, or called directly from application code?
- Does your contract include a data export clause with a defined format and timeline?
- Have you actually tested an export and reimport at a small scale, or only read that it's possible?
Portability has a cost too, so decide where it's worth paying
Full portability everywhere is its own tax: abstraction layers add latency and engineering time, and some vendor-specific features genuinely aren't available elsewhere, so an interface built for the lowest common denominator can mean giving up capability you'd actually use. The honest approach is to decide which layers are worth the portability cost, usually the ones with the highest switching cost if you get locked in, and accept vendor-specific convenience in the layers where switching would be cheap anyway.
When lock-in is actually the right trade
Not every lock-in is a mistake. If a vendor's managed reranking model consistently outperforms what you could build yourself, and the cost of that dependency is lower than the engineering time to stay portable, take the dependency and write down why. The goal isn't zero lock-in, it's knowing exactly where you have it and what it would cost to undo, so a vendor's pricing change or an outage becomes a budgeting conversation instead of a surprise.
What Good Looks Like
Good vendor-risk management for a vector search stack means you know exactly which layers would be expensive to leave, and you've actually tested an export, not just read that one exists.
Building The Capability (5-Stage Skill Ladder)
How to Get Started
Frequently Asked Questions
What's the biggest source of vendor lock-in in a RAG stack?
The biggest source is the retrieval logic built on top of the database, not the database itself, since raw vectors are portable. Reranking, hybrid search, and metadata filtering that call a vendor's proprietary API directly from application code, instead of through your own interface, are what make a switch expensive.
Should I avoid all vendor-specific features to stay portable?
No. Full portability everywhere has its own cost in engineering time and lost capability. Decide which layers carry the highest switching cost if you got locked in, and accept vendor-specific convenience in the layers where switching would be cheap anyway.
How do I estimate the real cost of switching vector database vendors?
Work out how long and how much it would cost to re-embed your full corpus with a new provider's model, since that's usually the largest and least avoidable part of any migration. Revisit that estimate alongside your regular capacity planning as the corpus grows.
About the numbers
This guide doesn't quote a sourced benchmark. Figures in it are estimates or general guidance, so check them against your own numbers.
Related Guides
Choosing a Distributed Locking Pattern Without Overbuilding It
A decision guide for choosing a distributed locking approach, from a simple database row lock to a dedicated coordination service, based on what you need.
A Go-Live Checklist for Shipping a RAG Pipeline
The specific steps to check before a RAG pipeline goes live: index warm-up, model version pinning, a canary check, and a real rollback plan.
The Real Cost of Vendor Lock-In (and When to Actually Migrate)
How to tell whether a vendor dependency is a real business risk or just an inconvenience, and what a realistic exit actually costs you.
The Vendor Exit Checklist: What to Verify Before You Depend on a Platform
A checklist for CTOs to run before adopting a platform vendor, covering the export paths, contract terms, and pitfalls that turn dependence into lock-in.
Zero Trust for a RAG Pipeline Means No Service Gets a Free Pass
A decision framework for applying zero trust to a production RAG pipeline: verifying every service and user call, not just the ones at the edge.
Where RAG Latency Actually Goes, and How to Budget It
Break a RAG request into its four latency stages, find out which one is actually slow, and set a budget for each before you start tuning blindly.