DBreeze: an embedded ACID data layer for .NET that also does text, vector and multi-parameter search

What DBreeze actually replaces in a .NET stack

The pitch in the README is a list of subsystems, not a single product: an embedded key-value store, an object database layer, a full-text and partial text search subsystem, a multi-parameter search subsystem, and a vector similarity and clustering layer built on HNSW graphs with TurboQuant vector compression. All of it lives in one assembly with, in the README's words, "without references to other libraries."

That matters most for a specific kind of application: a desktop, mobile or IoT .NET process that needs durable local state, transactional writes, and some form of search, but cannot justify running a database server next to it. In that setting the usual answer is to embed a key-value store and then add a separate full-text engine and a separate vector index, each with its own persistence, its own consistency model and its own failure modes. DBreeze's claim is that these layers share the same storage engine and the same ACID transaction machinery, so a write and its search index update are not two independent systems that can drift apart.

The audience is narrow but real: C# developers on .NET Framework 3.5 and later, .NET Core 1.0 and later, .NET Standard 1.6 and later, UWP, Unity, CoreRT, and via Xamarin on Android and iOS. If your service is written in Go or Python and merely talks to a database, DBreeze is not the tool, because the data layer is an in-process library, not a wire protocol.

Liana-Trie indexing and the byte-array contract

Two design decisions shape everything else. The first is that keys and values are, at the low level, always byte arrays. The README is explicit about this: "Keys and values, on the low level, are always byte arrays." Typed access is a conversion layer on top, and the project bundles its own binary and JSON serializer, Biser.NET, for that purpose. This is why the storage engine can be indifferent to whether you are storing a protobuf message, a document, or a float array for the vector layer.

The second is the index. DBreeze uses what the README calls Liana-Trie indexing, with the claim that database indexes never need defragmentation and that insert, update and remove speed does not degrade over time. That is a meaningful contrast with B-tree storage engines, where page splits and fragmentation are a recurring operational concern. The README also states that updates can reside in the same physical space "when possible or configured," which implies a tunable trade-off between write amplification and space reclamation rather than a fixed policy.

The size limits are stated plainly: maximum key size 65KB, maximum value size 2GB, and a value can be represented as a set of columns holding fixed or dynamic length data, with each dynamic block up to 2GB. Tables have no fixed schema and can be created and accessed on the fly, and they can live in mixed locations: different folders, different drives, memory, or in-memory with disk persistence. Nested or fractal tables can reside inside values of master tables. There is also a documented ability to access a key/value pair by physical link, which the README frames as a way to save time when joining data structures. That last feature is the one most likely to be misunderstood: a physical link is only meaningful while the record stays where it is, and the README does not describe what happens to such links after a move or compaction.

Installing DBreeze from NuGet and writing a first table

The README points to NuGet as the distribution channel and states that DBreeze has been on NuGet since January 2014. Assemblies are also published under the repository's releases, and the README notes that all NuGet DLLs are digitally signed with anti-tampering protection. The package name is DBreeze.

dotnet add package DBreeze

The README does not include a minimal code sample, but it does point to Quick start guides in the project wiki and to a PDF and HTML documentation set, plus an LLM-oriented markdown file at Documentation/LLM/DBreeze4LLM_004_compressed.md. The repository layout confirms the multi-target structure: DBreeze.Net5/, DBreeze.Net8/, DBreeze.NetCoreApp/, DBreeze.NetStandard/, DBreeze.Portable.Tests/ and a legacy NETPortable/ folder. Pick the project that matches your target rather than assuming one folder covers all of them.

The typical first step described across those guides is opening a database against a folder path and then obtaining a table, since table names are not pre-declared. The README states that tables can be created and accessed on the fly and that tables can reside in different folders, drives or memory, so the path you pass determines where that table's data lands. For a first real use, start with a single table in a local folder, insert a handful of byte-array key/value pairs, and read them back with a forward range traversal. The README lists range select and traversal modes including forward, backward, from/to, skip and StartsWith, plus the ability to remove and change keys. That traversal API is the part worth exercising early, because it is what you will build queries on if you skip the higher-level search subsystems.

Where the search layers sit and what they cost you

DBreeze bundles three query-oriented layers above the key-value core. The first is an integrated text search subsystem for full-text and partial matching. The second is a multi-parameter search subsystem, which the README describes as fast with "powerful query possibilities" but does not specify an index format or a query language in the documentation it links. The third is the vector layer: a similarity search engine and clustering facility based on HNSW graphs, with TurboQuant vectors compression.

The vector layer is the most interesting and the least documented in the README. HNSW is an approximate nearest neighbour method, which means recall is a tuning parameter, not a guarantee. TurboQuant compression reduces the memory footprint of stored vectors, and compression of vectors generally trades recall against that footprint. The README does not state recall figures, memory-per-vector numbers, or how the graph parameters are exposed. If you are evaluating DBreeze for vector search, that is the gap to close before you commit: read the documentation linked from the README and confirm what knobs exist and what their defaults are.

The text and multi-parameter layers carry a different risk. Because they are integrated rather than external, their capabilities are bounded by what the project has implemented. There is no plugin ecosystem to fill gaps, and the README does not describe an extension point. If your search requirements are already well served by a mature standalone engine, you are paying for integration you may not need.

Multi-threading, ACID scope and the deadlock story

DBreeze describes itself as multi-threaded and ACID compliant, with "a solution for deadlocks resolving/elimination, parallel reads and synchronized writes/reads." That phrasing is worth reading carefully. Parallel reads with synchronized writes is a reader-writer model, and it means write throughput is bounded by serialization on the write path. The README's performance numbers are explicitly historical: it cites 500,000 key/value pair inserts or 260,000 updates per second per core into a sorted table on a standard PC, and labels the benchmark as being from 2012. Treat those as an order-of-magnitude indication of the engine's design intent, not as a figure to plan capacity around.

The more consequential question is transaction scope. If the text index and the vector index are updated inside the same transaction as the primary record, you get consistency at the cost of longer write transactions and more contention. If they are updated outside it, you get better write throughput and the possibility of index drift. The README does not state which model applies to the search subsystems. This is the single most important thing to determine from the documentation before building on the integrated search layers.

High availability is handled outside the core: the README lists High Availability, Redundancy and Fault Tolerance via Raft.NET, a separate project by the same author. That is a deliberate boundary. DBreeze itself is an embedded single-process engine, and clustering is an add-on you would adopt separately.

When DBreeze is the wrong choice

The clearest disqualifier is language. DBreeze is a .NET library. If any part of your system that needs to read the data is not .NET, you would be exposing the database through a service you write yourself, at which point you have rebuilt the client-server architecture you were avoiding, with none of the maturity of an established server database.

The second is operational model. There is no server process, no network protocol, and no separate administration surface. That is a benefit for a desktop or mobile app and a liability for a shared multi-tenant backend where several independent services need concurrent access to the same dataset.

The third is query sophistication. DBreeze gives you key traversal, a multi-parameter search subsystem and a text search subsystem. It does not give you SQL, a cost-based query planner, or the relational tooling that surrounds those. If your team's mental model is tables, joins and an ORM, adapting to byte-array keys and range traversals is real work, and the README's own framing, that DBreeze is "a foundation for complex data storage solutions," is a fair warning that you are expected to build the upper layers.

Finally, consider the ecosystem. The README notes DBreeze is listed in nosql-database.org, Awesome .NET Core and awesome-dotnet. Those are directory listings, not evidence of a large community. The project is a single-maintainer effort with a contact address in the README, and the documentation is spread across a wiki, a PDF, a Google Doc and a markdown file rather than consolidated in the repository. Plan for reading source when the docs run out.

Licence, upgrades and what maintenance actually looks like

The repository LICENSE is BSD-2-Clause, while the README's own badge reads "BSD 3, FOSS." That discrepancy is worth resolving against the LICENSE file in the repository root before you rely on either label, since the two licences differ in whether the name of the copyright holder may be used to endorse derived products. The repository also contains a Licenses/ folder, which suggests bundled third-party terms exist; check it if your legal process requires a full inventory. This is a description of the files, not legal advice.

On maintenance: the repository is not archived, and the last push was on 2026-08-28. Recent releases are v1.138 on 2026-06-03, v1.137 on 2026-04-22 and v1.136 on 2026-04-03, so the release cadence has been roughly monthly to bi-monthly through 2026. The README states the code has been used in the author's own production environment since June 2012 and that DBreeze has been on NuGet since January 2014.

Upgrade cost is shaped by the multi-target layout. The repository carries separate project folders for .NET 5, .NET 8, .NET Core, .NET Standard and Portable, plus test and benchmark projects (DBreeze.Net5.Tests/, DBreeze.Net8.Tests/, DBreeze.Net8.Benchmarks/, DBreeze.Portable.Tests/) and audit tooling (DBreeze.ReleaseAudit.Protocol/, DBreeze.ReleaseAudit.Worker/). A version bump therefore means checking that the folder matching your target framework received the change, not just that the NuGet package version moved. The README does not document a rollback procedure, so if you need one, you will be designing it around the incremental backup and restore feature the README does list.

Editorial conclusion

Adopt DBreeze if you are shipping a .NET application that needs local transactions plus search, and you want one assembly instead of a key-value store bolted to a separate search engine. Skip it if your data must be reachable from non-.NET services, if you need a query planner and SQL, or if you want a large third-party ecosystem to lean on. Before committing, verify three things yourself: that the current build restores and runs on your target framework (the README claims .NET Framework 3.5 through .NET 8 and Xamarin, but the repository ships separate project folders per target, so check which one you actually need), that the vector layer's HNSW and TurboQuant behaviour matches your recall and memory budget, and that the documented backup path covers your restore scenario, because the README lists incremental backup and restore but does not spell out rollback semantics for a partially applied transaction.

Frequently asked questions

Official sources

1. hhblaze/DBreeze on GitHub
2. Issues
3. License: BSD-2-Clause
4. README
5. Releases