Zvec Setup: An In-Process Vector Database in Minutes

Zvec is Alibaba's lightweight, lightning-fast vector database that runs in-process, inside your application, with no server to deploy. Think of it as SQLite for vector search: an embedded engine you pip install and use directly. It is climbing GitHub trending past 13,000 stars because it fills a gap the heavyweight vector databases leave open, and this tutorial has you inserting and querying vectors in about a dozen lines of Python.

• Zvec is an in-process (embedded) vector database: no server, no container, it runs inside your app.
• Install is one line per language: pip install zvec, or npm, Go, Rust, and Flutter bindings.
• A full create, insert, query loop is roughly a dozen lines of code.
• It is Apache-2.0 and free, aimed at local, edge, and on-device search where a server is overkill.

What is Zvec and where does it fit?

Zvec is an embedded vector database. Where systems like Milvus or a hosted vector service run as a separate server you connect to over the network, Zvec runs in the same process as your code and reads and writes a local file. That is the SQLite model applied to similarity search, and it matters for a specific and growing set of workloads: a desktop app that needs semantic search over local files, an edge device doing on-device retrieval, a mobile app (there are Dart and Flutter bindings), or simply a prototype where standing up a vector server is more trouble than the problem deserves. It trends because in-process is the right default for those cases and the market has been dominated by server-first tools.

RelatedStrix Setup: Run an AI Penetration Tester on Your Code

How do you install and run a first query?

Install the SDK for your language. Python needs 3.10 to 3.14:

# Python
pip install zvec

# Node.js
npm install @zvec/zvec

The full lifecycle, define a schema, open a collection, insert vectors, and query for nearest neighbors, is short:

import zvec

schema = zvec.CollectionSchema(
    name="example",
    vectors=zvec.VectorSchema("embedding", zvec.DataType.VECTOR_FP32, 4),
)
collection = zvec.create_and_open(path="./zvec_example", schema=schema)

collection.insert([
    zvec.Doc(id="doc_1", vectors={"embedding": [0.1, 0.2, 0.3, 0.4]}),
    zvec.Doc(id="doc_2", vectors={"embedding": [0.2, 0.3, 0.4, 0.1]}),
])

results = collection.query(
    zvec.VectorQuery("embedding", vector=[0.4, 0.3, 0.3, 0.1]), topk=10)
print(results)

In production you replace the toy four-dimensional vectors with real embeddings from your model of choice.

What are the gotchas?

Three. Embedded is a design choice, not a limitation to fight: Zvec is built for single-process, local workloads, so if you need many services querying one shared, horizontally-scaled index, a server-based database is still the right tool. It is young, at version 0.5, so pin your version and read the changelog before upgrading. And the dimension and data type are fixed in the schema at creation, so match them to your embedding model up front. For its intended niche, none of these are drawbacks; they are the shape of an embedded database doing its job.

RelatedSet Up OpenAI Codex Inside Claude Code

When should you choose embedded over a vector server?

The decision is really about how many things need to query the same index at once. Choose embedded, and Zvec, when the search lives inside a single application: a desktop tool doing semantic search over local files, a mobile app with on-device retrieval, an edge device that must work offline, or a prototype where standing up a server is pure overhead. In all of those, in-process means no network hop, no container to run, and no service to keep alive, which is a real simplification. Choose a server-based vector database when many independent services need to hit one large, shared, horizontally-scaled index, or when your dataset outgrows what fits comfortably on a single machine. The mistake teams make is reaching for the heavyweight server by default because that is what the tutorials show, when their actual workload is single-process and local. Zvec is a reminder that, just as most apps do not need a database server and are perfectly happy with SQLite, most retrieval workloads do not need a vector server either.

Our take

Zvec is a bet that the vector-database market over-indexed on the server, and it is a good bet. Most retrieval workloads that developers hit day to day are local: a prototype, a desktop tool, an edge device, a mobile app. For all of those, spinning up and paying for a separate vector service is friction with no payoff, and an embedded engine you pip install is exactly right. The SQLite comparison is apt and flattering. It is early, so treat 0.x as early, but for adding semantic search to something that runs on one machine, this is the lowest-ceremony option going.

Original analysis by GenZTech. Tool documentation: alibaba/zvec on GitHub.