Rust · SQL · documents · vectors

Choosing a Rust embedded database for SQL, document, NoSQL, and vector workloads

“Written in Rust” and “embedded in a Rust application” are different claims. Start with the storage and query contract, then choose a library whose process boundary, durability, and data model match the application.

Short answer: use SQLite for mature relational storage, DuckDB for local analytical SQL, a focused key-value engine for ordered keys, a document store for document-native APIs, and MongrelDB when one Rust process needs transactional rows, JSON, analytical SQL, text, and vector retrieval together.

What “Rust embedded database” should mean

An embedded database runs in the application process and stores data under an application-owned path. A Rust client connected to a separate server is not embedded. A database implemented in another language can still be embedded through a stable native interface, while a Rust database can still require a daemon.

Decide whether one process owns the files, whether multiple processes need concurrent access, and whether the product can ship native binaries. Those constraints usually remove more candidates than a feature checklist.

Match the engine family to the workload

Primary needUseful baselineWhat to verify
Relational application stateSQLite through a Rust bindingExtension policy, migrations, connection model, and native-library packaging
Analytical SQLDuckDBWrite shape, memory limits, concurrency, and whether OLTP behavior is required
Ordered key-value storageredb or another focused KV engineTransactions, iteration order, compaction, and value encoding
Document-native APIPoloDB or another embedded document storeQuery coverage, schema evolution, indexes, and compatibility boundaries
Rows, JSON, SQL, text, and vectorsMongrelDBSingle-node scope, platform packaging, index behavior, and workload-specific limits

No row is a universal winner. A smaller engine with the right data model is usually safer than a broad engine selected for features the application will never use.

Rust embedded SQL database choices

For conventional relational state, SQLite is the benchmark to beat: mature transactions, a stable file format, broad tooling, and a large operational history. DuckDB serves a different center of gravity—columnar analytical work and local scans. Treating the two as interchangeable hides important differences in write patterns and concurrency.

MongrelDB uses DataFusion for SQL over its own WAL, MVCC, and PAX-style sorted runs. That makes it relevant when fresh operational rows and analytical projections must share one local engine. It does not make MongrelDB SQLite-compatible, and it does not provide DuckDB's ecosystem or file format.

Rust embedded document database and NoSQL choices

A document database is useful when application objects map naturally to documents and the document query API is the main interface. A key-value database is narrower: the application owns serialization and secondary lookup design. “NoSQL” alone does not distinguish those models.

Rust embedded NoSQL database boundaries

MongrelDB stores native JSON alongside typed columns, but it is not a MongoDB-compatible document database. Frequently filtered values should be modeled as typed indexed columns; arbitrary nested JSON paths do not automatically gain indexes. Choose a document-native engine when preserving a document API matters more than combining typed SQL and hybrid retrieval.

Where MongrelDB fits in a Rust process

MongrelDB is implemented in Rust and exposes the core engine as Rust crates. One storage root can hold typed operational rows, JSON, DataFusion SQL, Bitmap equality, learned ranges, FM substring search, HNSW or other ANN paths, sparse retrieval, and MinHash candidates. Those index families resolve to RowIds under one transaction and recovery model.

The main limit is architectural: the primary production profile is embedded or single-node server ownership. Use the daemon when several processes need one owner. Use a distributed database when independent scaling, managed multi-region failover, or shared remote ownership is the requirement.

Evaluation checklist

  1. Implement one production-shaped read and one durable transaction.
  2. Terminate the process during writes and verify recovery.
  3. Measure installation size, startup, memory, and file growth—not only query latency.
  4. Test backup and restore while respecting the engine's ownership rules.
  5. Verify every required query, migration, and platform before adopting a file format.
Compatibility rule: changing embedded engines is a data migration and API migration. Similar words such as SQL, document, or vector do not imply compatible behavior.
Free database inspection

MongrelDB Viewer

Open a MongrelDB root, inspect schema and indexes, run SQL, and test maintenance from the open-source desktop application.

Broader development workspace

Mongrel by VisorCraft

Use Mongrel when the same work spans MongrelDB, other database engines, terminals, files, containers, Kubernetes, and APIs.

Sources