The right replacement for a self-hosted vector database depends on how much infrastructure you want to run. Embedded and serverless options leave nothing to operate, tools already in your stack avoid adding a database, and a single-vendor server or cloud keeps one team responsible for the engine and the hosting.
Milvus is built for scale, and that's the problem for a lot of projects. Its docs say the mode designed for large production, Milvus Distributed, runs on Kubernetes, while Standalone is a single machine. If you don't want to run Kubernetes, you're pointed towards one box with enough memory, and working out how much memory means estimating from vector dimensions, scalar fields and index choice before you've stored anything.
If that feels like more operating than your app needs, you're the reader this page is for. I've grouped eight alternatives by how much you'd have to run yourself, from nothing at all to a server you manage, and listed them in no particular order further down. For a broader view of the field, our guide to the best vector databases compares the bigger names side by side.
Eight options at a glance
| Tool | Kind of engine | Good for |
|---|---|---|
| LanceDB | Embedded library | Vector search inside your app, with no server |
| Meilisearch | Search engine with AI retrieval | Mostly-search projects, self-hosted or on its cloud |
| Redis | In-memory data store | Teams already running it who want vector sets |
| Supabase | Hosted Postgres platform | Vectors beside your app data in hosted Postgres |
| turbopuffer | Object-storage search database | Large collections where memory sizing is the pain |
| Typesense | Open-source search engine | One simpler engine to self-host |
| Upstash Vector | Serverless vector index | Nothing to size: create an index in a console |
| Weaviate | Vector database with cloud | Open-source engine and managed cloud from one team |
How much do you want to run?
Nothing at all: embedded or serverless
These remove the server from the conversation. LanceDB runs inside your application as an embedded library, so there's no separate service to deploy, patch or watch. Upstash Vector goes the other way: you create an index in a console and the vendor runs everything behind it. turbopuffer is built on object storage, which the vendor positions as the answer for big collections, the case where sizing memory for a Milvus box gets painful.
Something you already run
Often the lightest move is not adding a database at all. Redis now offers vector sets as a data type, so a team that already runs it can keep vectors next to its caching and queues. Supabase keeps embeddings in hosted Postgres alongside your users, storage and functions, which means one project, one backup routine and no extra cluster.
One server or cloud, from one vendor
If you still want a dedicated engine but simpler ownership, these keep the code and the hosting with the same team. Weaviate is open source with a managed cloud from the people who make the engine. Meilisearch and Typesense are search engines first, both open source and self-hostable, with vector search built in. They make the most sense when most of what you're doing with Milvus is search for a site or app rather than a giant similarity index.
Are you leaving the engine or the service?
This is the point that trips people up. Milvus and Zilliz Cloud aren't the same purchase. The Milvus site sends you to Zilliz Cloud for the managed version, and Zilliz now describes its product as a Vector Lakebase powered by Milvus. So the open-source project and the managed service are positioned differently, and leaving Milvus can mean two different things: leaving the engine you host, or leaving the service someone hosts for you.
If it's the engine that hurts, most of the options above remove the operating work. If it's the service, you may be happier with another managed cloud than with any self-hosted tool. Work out which one you mean before you start comparing, because the shortlist changes completely.
Pace matters too. The docs list v2.4, v2.5, v2.6 and v3.0 lines; Milvus 3.0 was announced on 27 Jul 2026, adding lake-native vector search, and v3.0.5 shipped on 30 Oct 2026. Moving between Milvus modes is itself a migration: the docs say the client API is similar, but you should check feature differences and migrate stored data separately, and an existing Milvus Lite 2.x file needs export and migration for Lite 3.x. If you're facing a migration anyway, that's a natural moment to test something else.
New to the idea and not sure you need a dedicated vector store at all? Our plain explainer on what a vector database does is a good place to start.
My advice on picking a lighter option
Start from the thing you'd most like to stop doing. If it's running servers, go embedded or serverless and accept a little less control. If it's running another database, put vectors in the store you already operate and see how far it takes you. If you're happy to run an engine but tired of Kubernetes, pick a single-vendor server with a managed cloud you can move to later.
Whatever you choose, don't decide on a benchmark page. Take a real slice of your own data, your own queries and your own filters, load it into two candidates and compare recall and speed with your eyes open. Vector search behaves very differently on your data than on anyone's demo.
All eight, in no particular order
LanceDB
Best for: Developers who'd rather run retrieval inside the application itself, using an open-source embedded library built for multimodal AI data.
Meilisearch
Best for: Projects where vectors are really about search, with an open-source engine you self-host or a fully managed cloud version.
Redis
Best for: Teams that already run this data store and would rather use its vector sets data type than add another database to look after.
Want AI doing the heavy lifting in your marketing?
I build the systems that handle the boring 80 percent, so you get your week back. Done properly, with the human kept in.
Supabase
Best for: App builders who want vector embeddings in the same hosted Postgres project as their auth, APIs, storage and functions.
turbopuffer
Best for: Large collections needing vector and full-text search, from a database the vendor built on object storage.
Typesense
Best for: Site and app search with typo tolerance and vector search, in an open-source engine you can host yourself.
Upstash Vector
Best for: Small teams that want a serverless vector index created in the Upstash console, with no cluster to install or plan.
Weaviate
Best for: Teams wanting an open-source vector platform for search, RAG and agents, with a managed cloud and hosted embeddings from the same people.
A five-step pilot before you migrate
- Write down the pain. Kubernetes, memory sizing, upgrades or the managed service: one line, so you can test against it.
- Export a representative slice. Take real vectors with their scalar fields, not a toy sample, and note the index type you use now.
- Load it into two candidates. One that removes the server and one that keeps a server you control.
- Run your real queries. Include filters and hybrid search if you use them, and compare results against what you get today.
- Plan the cutover. Keep your search calls behind a small layer in your own code, so switching vendors later means rewriting that layer, not your app.
Do you make a vector database or vector search engine? Tool makers can ask to be considered for a featured place on this list.
Want your tool on this list? Featured spots and reviews here are paid partnerships. Here's how to partner with me.
Frequently asked questions
Do I need Kubernetes to run Milvus?
Not for every mode. The Milvus docs say Distributed, the mode for large production, runs on Kubernetes, while Standalone runs on a single machine and Lite is a lighter local option.
Is Zilliz Cloud the same thing as Milvus?
They're related but positioned differently. Zilliz Cloud is the managed service the Milvus site points to, and Zilliz describes it as a Vector Lakebase powered by Milvus.
Can I keep vectors in a database I already use?
Often, yes. Some in-memory stores and hosted Postgres platforms now support vectors, which saves running a separate cluster. Test it on your own data volume first.
What's the easiest vector search option with nothing to run?
An embedded library or a serverless index. An embedded library runs inside your app; a serverless index is created in a console and the vendor runs the rest.
How do I move my data out of Milvus?
Export your vectors with their scalar fields and IDs, then load them into the new store and rebuild the index there. Check the new tool's docs for its import format before you start.
Should I upgrade Milvus or switch?
If you're facing a migration between versions or modes anyway, run a short pilot of an alternative at the same time. Compare both on your real queries, then decide.
