# LiteDB: a .NET document store in one file

> LiteDB is an embedded NoSQL document database for .NET that keeps everything in a single data file. It suits desktop tools and small apps; it is not a server database, and the README's encryption feature is explicitly disabled.

**litedb-org/LiteDB** — LiteDB - A .NET NoSQL Document Store in a single data file

- Repository: https://github.com/litedb-org/LiteDB
- Website: http://www.litedb.org
- Stars: 9,481 · Forks: 1,326
- Language: C#
- License: MIT
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/litedb-org-litedb

## The problem LiteDB solves: a document store with no server

Most NoSQL document databases assume a server process somewhere else: you run it, you connect over a socket, you manage its lifecycle. That is a poor fit for a desktop application that needs to ship as a single executable, or for a tool whose users expect their data to sit in one file they can copy. LiteDB targets exactly that gap. The README describes it as a "small, fast and lightweight .NET NoSQL embedded database" and lists the intended uses: desktop and local small applications, application file formats, small web sites, and one database per account or user.

The API will look familiar if you have used MongoDB. Collections hold documents, documents map to POCO classes, and queries can be written with LINQ or a SQL-like syntax. The storage model is closer to SQLite: one data file on disk, no daemon, no connection string pointing at a host. The project is written in C# and distributed as a single DLL under 450kb, targeting .NET 4.5 and NETStandard 1.3/2.0. It is the combination of those two lineages, document API plus single-file storage, that defines the project.

## How the storage engine and query path actually work

LiteDB maps your classes to BsonDocument instances, either through attributes or through the fluent mapper API. The README shows both: a plain Customer class with an auto-incremented Id, and a more complex Order class where the mapper declares cross-collection references with DbRef and an embedded sub-document with Field. That distinction matters at query time. Embedded documents travel with their parent. DbRef references do not, so a query that needs the referenced data must ask for it with Include, as the README does for Customer and Products on an Order query.

Indexes are explicit. The example calls EnsureIndex on the Name field with a uniqueness flag before inserting, and the README notes that a LINQ query on Age runs with no index. That is the normal trade-off: indexed fields are fast, unindexed scans are not, and nothing creates the index for you.

On durability, the README states ACID compliance with full transaction support and data recovery after write failure via a WAL log file. The v5 notes describe the locking model: read operations take no locks and allow multiple readers, while write locks are held per collection, allowing multiple writers. That is a meaningful design choice for a file-backed store, but it is also where the limits live, since the file is still a single file.

## Installing LiteDB from NuGet and a first real collection

The README gives one installation instruction: install from NuGet with the package name LiteDB. The related searches for "litedb nuget" point at the same place, so the package manager console command below is the entry point for a .NET project.

```bash
Install-Package LiteDB
```

After the package is restored, the README's quick example opens a database file, gets a typed collection, creates an index and inserts a document. The file is created if it does not exist. Note that EnsureIndex is called before Insert, and that Id is auto-incremented, so you do not set it yourself.

```C#
using(var db = new LiteDatabase(@"MyData.db"))
{
    var col = db.GetCollection<Customer>("customers");
    col.EnsureIndex(x => x.Name, true);
    col.Insert(customer);
    var results = col.Find(x => x.Age > 20);
}
```

For a first run you should see a MyData.db file appear next to your application, and the Find call should return the customer you inserted because Age is 39. If you need to inspect what landed in the file, the README points to LiteDB Studio as a UI for data access, and lists other viewers and editors in its plugins section, including OneBella, which the README describes as cross platform across Windows, macOS and Linux.

## Where LiteDB is the wrong tool

The README is unusually direct about one limitation: the datafile encryption entry is struck through with the note that the implementation is "currently not secure" and the instruction not to use it. Any application whose threat model includes someone reading the data file at rest should treat that as a hard stop rather than a caveat. There is no documented alternative for encrypting the file in the README.

The second boundary is concurrency across processes. The locking model described in the v5 notes is about threads inside one process, with per-collection write locks and lock-free reads. An embedded single-file database is not a coordination point for several separate applications writing concurrently. If your workload is a service with many clients, a shared file on a network share, or anything that needs a connection string to a host, LiteDB is the wrong shape.

Scale is the third. The README offers no size limits, no benchmark figures and no guidance on when a database outgrows the format, so I will not invent one. What the README does say is where it belongs: desktop and local small applications, application file formats, small web sites, and one database per user. Read that list as the intended envelope rather than as marketing.

## LiteDB vs SQLite, and the alternatives worth naming

The most common comparison is LiteDB against SQLite, and the difference is the data model rather than the packaging. Both keep data in a single file with no server. SQLite is relational: tables, columns, SQL, and a schema you migrate deliberately. LiteDB is a document store: collections of BSON documents, LINQ and a SQL-like query syntax, and POCO mapping that lets a C# class define the shape of the data. If your objects have variable or nested structure and you would rather not write joins, LiteDB's model saves work. If your data is naturally tabular and you want a mature relational query planner, SQLite is the better fit. The README does not publish a comparison or benchmark against SQLite, so any performance claim in that direction would be guesswork.

Against MongoDB, the difference is architectural. MongoDB is a server you deploy and connect to, with its own operational surface. LiteDB is a library inside your process with a file on disk. The README presents the API as similar to MongoDB, which lowers the learning cost but does not make the two interchangeable: one scales horizontally across machines, the other lives and dies with your application. The related searches also pair LiteDB with RavenDB, another .NET document database, but the README says nothing about RavenDB's design, so I will not draw a comparison I cannot support.

## Maintenance status, versions and the MIT licence

The repository is not archived, and the last push was on 2026-09-21. The most recent release is 6.0.0-prerelease.114 from 2026-09-13, preceded by v6.0.0-prerelease.77 in February 2026 and v6.0.0-prerelease.0075 in January 2026. The pattern is worth reading carefully: the 6.0 line is still published under prerelease tags, while the README's feature list is written around "New v5". If you are starting today, check which major version the NuGet package resolves to and whether the API in the README matches it, because the documentation and the newest release tags are not obviously describing the same version.

The licence is MIT. That permits commercial use, and the README states the project is "open source and free for everyone - including commercial use". MIT carries no copyleft obligation on your own code, but it also comes with no warranty, and this is a summary rather than legal advice. One practical implication of a permissively licensed embedded library: because there is no server to operate, the upgrade cost is mostly your own code. A version bump means recompiling against a new DLL and re-testing your queries and indexes, not running a migration on a fleet of servers. There is a LiteDB.Migration framework listed in the plugins section for schema migrations, which the README describes as making migrations easier, though it is a separate project rather than part of the core library.

## Conclusion

Adopt LiteDB when your .NET application needs a local, single-file document store with a MongoDB-like API and no separate server process: desktop tools, application file formats, or one database per user. Do not adopt it if you need a networked database, multiple processes writing to the same file, or encryption, since the README states the DES/AES implementation is not secure and must not be used. Before committing, verify the current state of the 6.0 line, which is still at prerelease tags such as 6.0.0-prerelease.114, and confirm that the API surface you depend on matches the version you install rather than the v5 documentation.

## FAQ

### What is LiteDB?

LiteDB is a .NET NoSQL embedded document database that stores data in a single file, with an API the README describes as similar to MongoDB. It is written in C#, ships as a single DLL under 450kb, and installs from NuGet as the package LiteDB.

### How do I install LiteDB?

The README gives one instruction: install from NuGet with Install-Package LiteDB. Opening a LiteDatabase against a file path creates the data file if it does not already exist.

### How do I use LiteDB in C#?

The README's quick example opens a LiteDatabase on a .db path, calls GetCollection with your POCO type, optionally calls EnsureIndex, then Insert, Update and Find. Queries can use LINQ expressions such as Find(x => x.Age > 20) or the SQL-like syntax.

### Is LiteDB thread safe?

The README lists thread-safe as a feature. The v5 notes add that read operations take no locks and allow multiple readers, while write locks are held per collection, allowing multiple writers. That describes threads within one process, not separate processes sharing a file.

### What are the key differences between SQLite and LiteDB?

Both store data in a single file with no server, but SQLite is relational and LiteDB is a document store with BSON documents, POCO mapping and LINQ queries. The README does not publish a benchmark comparing the two.

### Is LiteDB dead?

The repository is not archived and the last push was on 2026-09-21, with the most recent release tagged 6.0.0-prerelease.114 on 2026-09-13. The 6.0 line is still published as prerelease versions.

## Sources

- [License: MIT](https://github.com/litedb-org/LiteDB/blob/dev/LICENSE)
- [litedb-org/LiteDB on GitHub](https://github.com/litedb-org/LiteDB)
- [Project website](http://www.litedb.org)
- [README](https://github.com/litedb-org/LiteDB/blob/dev/README.md)
- [Releases](https://github.com/litedb-org/LiteDB/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/litedb-org-litedb