An embedded database with vector search: what to require, and who actually offers it.

Requirements that separate databases from demos

1. One transactional boundary. The vector index and the row it describes must commit and delete together. If a crash or correction can leave the index disagreeing with the data, you have a demo, not a database.
2. Retrieval signals plural. Real queries mix vector similarity with exact text, metadata equality, ranges, and recency. A store that only does nearest neighbors pushes that work into your application.
3. A scan-cost story. Exact brute-force KNN is honest and fine at small scale; know the vector count where it stops being fine, and whether the engine has an ANN index waiting.
4. Backup and encryption that cover everything. Vectors, documents, and operational rows should snapshot together, and private data should not sit in an unencrypted index.
5. A license you can ship. All options on this page are permissively licensed; that is not universal in this space, so check before committing.

The options

One notable non-option: pgvector is excellent but not embedded; it runs inside a Postgres server. If your deployment can include Postgres, it belongs on your list; if the requirement is in-process, it does not qualify.

MongrelDB: the engine built for this exact shape

MongrelDB stores the source row, its embedding, sparse vector, text, metadata, timestamps, and set fingerprint in one table, with each signal using a specialized index resolving through the same RowId space. A hybrid query applies hard filters first, unions named retrievers, and fuses ranks with deterministic RRF, returning component and fused scores you can inspect.

Because it is a database and not only an index, the operational questions have direct answers: deletes and updates commit with the row, SQL joins retrieval results with the rest of the product's data, WAL and MVCC define crash behavior, and page-level AES-256-GCM encryption covers storage, WAL frames, result cache, and index checkpoints. It runs embedded through native bindings for Rust, Python, Node, and C FFI, or as a local mongreldb-server daemon.

sqlite-vec: the smallest real answer

sqlite-vec is a pure-C extension with no dependencies that adds vec0 virtual tables to SQLite: float, int8, and binary vectors, metadata in ordinary columns, everything in one normal database file. KNN is exact, via brute-force scan, with partition keys to bound the scan and FTS5 available for text when you assemble hybrid retrieval yourself. It inherits SQLite's ACID transactions, which is more than many vector stores can say.

The README is explicit that the project is pre-v1 and breaking changes are expected, and brute-force scans have an obvious cost ceiling. For applications that already ship SQLite, it is the right first step and an honest one.

LanceDB: columnar retrieval with hybrid search

LanceDB's open-source library runs embedded on the Lance columnar format with Arrow ecosystem integration: ANN indexing from the IVF-PQ family, a BM25 full-text index, hybrid search fusing vector and FTS with rerankers including Reciprocal Rank Fusion, SQL-style pre-filtering, and automatic data versioning. Its center of gravity is analytics and retrieval rather than OLTP-style operational rows, so test the update and delete path against your consistency requirements.

Chroma: collection-shaped prototyping

Chroma's embedded Python client stores documents, embeddings, and metadata in collections with metadata and document filters, Apache-2.0, and graduates to a server or Chroma Cloud if the prototype grows. It is a friendly start for RAG demos. Its documented conditional transactions are collection-scoped with explicit limits, so treat it as a document and embedding store rather than a system of record.

How to choose

Choose MongrelDB when

• the vector index must share a transactional boundary with operational rows;
• retrieval mixes vectors with exact text, metadata, ranges, and dedup;
• encryption at rest and SQL are requirements, not extras;
• the database ships inside a product: desktop apps, agents, devices, daemons.

Choose the others when

• you already ship SQLite and vector counts are modest: sqlite-vec;
• the workload is columnar retrieval with versioning: LanceDB;
• a collection API for a prototype is enough: Chroma;
• a Postgres server is allowed: pgvector, from our alternatives roundup.

Evaluation checklist

1. Write, update, and delete a row, then query immediately; confirm the index cannot return the deleted state.
2. Run one query mixing vector similarity, a metadata filter, an exact phrase, and a time bound.
3. Measure scan cost at ten times your launch vector count, not your demo count.
4. Restore a backup in a clean directory and verify vectors and rows agree.
5. Confirm encryption covers the index files, not only the data files.

Embedded vector database FAQ

What is an embedded database with vector search?

A database that runs inside your application process, with no server to deploy, and can index and query vector embeddings beside ordinary data. MongrelDB, sqlite-vec, LanceDB, and Chroma's embedded client all fit; pgvector does not, because it runs inside a Postgres server.

Which embedded database has vector search and SQL?

MongrelDB has full SQL with dense ANN, sparse, substring, bitmap, range, and MinHash indexes sharing one RowId space, plus MVCC transactions and AES-256-GCM encryption. sqlite-vec adds exact KNN to SQLite, which already has SQL and ACID transactions, with FTS5 for text. LanceDB supports SQL-style filtering and SQL queries over its tables.

Is sqlite-vec enough for production vector search?

For small to medium vector counts, yes: it is a pure-C extension doing exact KNN via brute-force scan inside a normal SQLite database, which is simple and dependable. Its README marks it pre-v1 with breaking changes expected, and brute-force scans get expensive as vectors grow, so plan the exit to an ANN index before you need it.

Do I need a separate vector database if my database has vector search?

Usually not for embedded and product workloads. A separate vector service earns its keep when many applications share one retrieval cluster or when vector scale dominates everything else. If your vectors describe rows your application already owns, keeping them in the same embedded database removes a synchronization problem.

What should I test before committing to an embedded vector database?

The write path first: update and delete source rows and confirm retrieval cannot return stale state. Then a mixed query with vector similarity, a metadata filter, an exact phrase, and a time bound. Then backup, restore, and encryption. ANN quality numbers matter less than those operational answers for most product workloads.