A vector search library that runs inside your process, and inside your transactions.

What a vector search library actually is

"Vector search library" gets used for three different things, and picking the wrong shape costs you later:

1. Index-only libraries. FAISS and similar crates give you nearest-neighbor data structures: build an index in memory, ask it for the k closest vectors, and handle everything else yourself. They are honest tools, but "everything else" includes persistence, deletes, metadata filtering, text search, and crash recovery.
2. Client libraries for a service. The Qdrant and Weaviate client packages are libraries in the import sense; the actual index lives in a server you deploy and reach over the network. That is a fine architecture when you want a shared retrieval service, but it is not in-process search.
3. Embedded engines. MongrelDB puts the ANN index inside a database engine: the same commit that writes a row publishes it to the vector index, and the same query can mix similarity, exact text, and metadata filters. One shared library, one storage directory, one transactional boundary.

MongrelDB: vector indexes inside the storage engine

MongrelDB stores the source row and its embedding, sparse vector, text, metadata, timestamps, and set fingerprint in one table, with each signal using a specialized index that resolves through a single shared RowId space:

A hybrid query applies hard filters first, unions named retrievers, fuses ranks with deterministic reciprocal rank fusion, and returns component and fused scores you can inspect. SQL exposes the same machinery as scored table functions: ann_search_scored, sparse_search_scored, minhash_search_scored, set_similarity_scored, and hybrid_search_scored, with ann_search_exact for exact reranking of approximate candidates from stored full-precision vectors.

The operational story is the point of the embedded shape. Writes go through an append-only WAL with group commit under MVCC snapshot isolation, so a delete commits with its row and the index cannot return stale state. Page-level AES-256-GCM encryption covers sorted-run pages, WAL frames, the result cache, and index checkpoints. Full SQL (DataFusion) with joins, recursive CTEs, and window functions sits over the same tables, so retrieval results join directly with the rest of your product's data.

Honest tradeoffs

When a service is the right call

Qdrant and Weaviate are good at what they are: shared vector services with their own clustering, dashboards, and ecosystems. If many applications query one central retrieval cluster, or a dedicated team will operate the service, the network hop is a fair price. The cost shows up when a single application owns its data and still pays a network round trip, a second deployment, and a synchronization problem between the service and the system of record.

When FAISS is enough

FAISS is the right tool when you genuinely only need an index: a batch job that builds once and queries read-only, a research pipeline, a component inside a larger system that already solved storage. It gives you indexes only, so you own persistence, deletes, filtering, and consistency. Teams often start there and rebuild the surrounding database poorly; if you need the surrounding database, start with one.

What MongrelDB costs you

Embedding a storage engine means linking a native library and giving it a directory; one process owns one storage core at a path, so multi-process access goes through the optional mongreldb-server daemon. It is single-node by design. And we publish no benchmark numbers on this page on purpose: measure on your own vectors and hardware before you commit.

Languages and linking

The engine ships as a single shared library (.so, .dylib, or .dll) with prebuilt archives for Linux, macOS, and Windows on every release. Native in-process bindings exist for Rust (cargo add mongreldb-core), TypeScript and Node.js (npm install @visorcraft/mongreldb, a NAPI addon with zero serialization overhead), Python (pip install mongreldb-kit), C and C++ through the C ABI, C#/.NET via P/Invoke, and Java, Kotlin, and Scala through JNI. Twenty-six more languages, including PHP, Go, Ruby, and Swift, use pure HTTP clients against the optional daemon when an in-process binding is not the fit.

How to choose

Choose MongrelDB when

• the vector index must commit, roll back, and delete with the rows it describes;
• queries mix dense similarity with exact text, metadata, ranges, and dedup;
• the database ships inside a product: desktop apps, agents, devices, daemons;
• encryption at rest and SQL are requirements, not extras.

Choose something else when

• you need a shared, centrally operated retrieval cluster: Qdrant or Weaviate, see our Qdrant alternatives roundup;
• you only need index structures inside a system that already has storage: FAISS;
• you already ship SQLite and vector counts are modest: sqlite-vec, covered in our embedded vector search guide.

Evaluation checklist

1. Insert, update, and delete a row, then query immediately; confirm the index cannot return uncommitted or deleted state.
2. Run one query mixing vector similarity, a metadata filter, an exact substring, and a time bound.
3. Measure index build and query latency at ten times your launch vector count, on your hardware, not from anyone's landing page.
4. Kill the process mid-write, reopen, and verify the index and the rows still agree.
5. Confirm the linking story for your language: shared library, package manager artifact, and license (MongrelDB is MIT or Apache-2.0).

Vector search library FAQ

What is a vector search library?

A library you link into your application that builds and queries vector indexes in-process, with no server to deploy and no network hop per query. The category splits in two: index-only libraries like FAISS, which give you nearest-neighbor structures and nothing else, and embedded engines like MongrelDB, where the vector index lives inside a full storage engine with WAL, transactions, and SQL.

What is the difference between a vector search library and a vector database service?

A service such as Qdrant or Weaviate runs as a separate process you deploy, secure, and reach over HTTP or gRPC; every query pays a network hop and every write crosses a system boundary. A library runs inside your process, so queries are function calls and the index can share a transaction boundary with the rest of your data. Services are the right shape when many applications share one retrieval cluster; libraries win when one application owns its data.

Why not just use FAISS for vector search?

FAISS is an excellent index library, but indexes are all it gives you. Storage, persistence, deletes, metadata filters, text search, transactions, and crash recovery are yours to build and to keep consistent with the index. MongrelDB uses HNSW and other ANN structures inside a storage engine, so the index, the WAL, and the rows commit together and you query them with SQL.

Does the MongrelDB vector index share transactions with the rest of my data?

Yes. Dense, sparse, substring, bitmap, range, and MinHash indexes all resolve through one shared RowId space over the same tables. An insert, update, or delete commits through the WAL under MVCC snapshot isolation, so the index can never return a row the transaction did not commit, or keep returning one you deleted.

Which languages can embed MongrelDB as a vector search library?

MongrelDB ships as a single shared library (.so, .dylib, or .dll) with native in-process bindings for Rust, TypeScript and Node.js (NAPI), Python (mongreldb-kit), C and C++ (C ABI), C#/.NET, Java, Kotlin, and Scala. Twenty-six more languages, including PHP, Go, Ruby, and Swift, connect through pure HTTP clients to the optional mongreldb-server daemon.

Can I combine vector similarity with filters and text search in one query?

Yes. MongrelDB hybrid search applies hard filters first (bitmap equality, PGM learned ranges, FM-index substring), unions named dense and sparse retrievers, then fuses ranks with deterministic RRF and returns component and fused scores. SQL exposes the same machinery as scored table functions such as ann_search_scored, sparse_search_scored, and hybrid_search_scored.