LiteDB is an open-source, MIT-licensed embedded NoSQL document database for .NET, distributed as a single DLL under 450 KB and storing an entire database in one data file.

What it is

LiteDB is a serverless NoSQL document store written entirely in C# and shipped as a single assembly for .NET 4.5 and NETStandard 1.3/2.0. Rather than running as a separate service, it is linked directly into a .NET application, which opens the database by pointing at a file path such as MyData.db. Documents are stored as BsonDocument values, and application classes are mapped to them through attributes or the fluent mapper API, so ordinary POCO types can be persisted and queried without an object-relational layer.

The concrete problem it solves is the need for a document database inside desktop, mobile, and small-server .NET applications where installing and administering a database server is not practical. It lives in the .NET ecosystem and replaces the combination of a separate database server plus a data-access layer, in the same way SQLite replaces a client-server relational database for single-file storage. The v5 storage engine supports multiple concurrent readers with no locks on read operations and write locks per collection, so multiple writers can proceed against different collections. It also replaces ad-hoc file and BLOB storage by offering stream and file storage inside the same data file, comparable to GridFS in MongoDB.

Key capabilities

• Serverless embedded execution: the database runs in-process inside the application, with no separate server to install or manage.
• Single data file storage: all collections, indexes, and documents live in one file, in the manner of SQLite.
• ACID transactions with full transaction support and a WAL log file that enables data recovery after a write failure.
• Thread-safe access under the v5 engine, which allows multiple readers without locks and applies write locks per collection.
• POCO mapping through attributes or the fluent mapper API, including DbRef for one-to-one and one-to-many cross-document references and embedded sub-documents.
• Indexing of document fields via EnsureIndex, for example col.EnsureIndex(x => x.Name, true) to create a unique index.
• LINQ query support such as col.Find(x => x.Age > 20), alongside SQL-like commands for accessing and transforming data.
• File and stream storage inside the database, similar to GridFS in MongoDB.
• Partial document load at the root level, plus internal and system collections introduced in v5.

Who uses it and how

• .NET desktop and client applications that ship as a single installable artifact and need local persistence without asking users to run a database server.
• Small web and service deployments where a single-process application owns its data file and wants MongoDB-style document modeling without operating a MongoDB cluster.
• Applications storing small binary assets and streams, using the built-in file storage in place of an external object store.
• Development and testing environments where a real database server is unavailable, since the database can be created on disk by opening a connection.
• Teams that already model data as POCO classes and want document persistence with LINQ queries rather than mapping to relational tables.

Getting started

Install from NuGet with Install-Package LiteDB, then open the database in code with new LiteDatabase(@"MyData.db") and obtain a collection through db.GetCollection("customers"). A companion UI, LiteDB Studio, provides graphical access and visualization of the same data files.

How it compares

Among the tools named in the project's own documentation, LiteDB positions itself against SQLite for single-file storage and against MongoDB for document modeling, a simple API of similar shape, and GridFS-style file storage. It differs from MongoDB in that it is embedded rather than a server, so there is no network layer, no cluster, and no separate process to operate. Compared with SQLite it offers schema-free documents, BsonDocument storage, and LINQ-native queries instead of SQL over relational tables.

When to use it — and when not to

A self-hoster operates no server, but does own the data file: backups, file placement, disk space, and write-failure recovery through the WAL log are the adopter's responsibility. Do not use it when multiple application processes or hosts must write to the same database concurrently, and do not rely on the datafile encryption option, which the README marks as currently not secure with the instruction "DO NOT USE". The project also carries a substantial open-issue count, and the broken encryption option should be treated as an absent feature rather than a safeguard when planning sensitive data.

// Create your POCO class
public class Customer
{
    public int Id { get; set; }
    public string Name { get; set; }
    public int Age { get; set; }
    public string[] Phones { get; set; }
    public bool IsActive { get; set; }
}

// Open database (or create if doesn't exist)
using(var db = new LiteDatabase(@"MyData.db"))
{
    // Get customer collection
    var col = db.GetCollection<Customer>("customers");

    // Create your new customer instance
    var customer = new Customer
    { 
        Name = "John Doe", 
        Phones = new string[] { "8000-0000", "9000-0000" }, 
        Age = 39,
        IsActive = true
    };

    // Create unique index in Name field
    col.EnsureIndex(x => x.Name, true);

    // Insert new customer document (Id will be auto-incremented)
    col.Insert(customer);

    // Update a document inside a collection
    customer.Name = "Joana Doe";

    col.Update(customer);

    // Use LINQ to query documents (with no index)
    var results = col.Find(x => x.Age > 20);
}

// DbRef to cross references
public class Order
{
    public ObjectId Id { get; set; }
    public DateTime OrderDate { get; set; }
    public Address ShippingAddress { get; set; }
    public Customer Customer { get; set; }
    public List<Product> Products { get; set; }
}        

// Re-use mapper from global instance
var mapper = BsonMapper.Global;

// "Products" and "Customer" are from other collections (not embedded document)
mapper.Entity<Order>()
    .DbRef(x => x.Customer, "customers")   // 1 to 1/0 reference
    .DbRef(x => x.Products, "products")    // 1 to Many reference
    .Field(x => x.ShippingAddress, "addr"); // Embedded sub document
            
using(var db = new LiteDatabase("MyOrderDatafile.db"))
{
    var orders = db.GetCollection<Order>("orders");
        
    // When query Order, includes references
    var query = orders
        .Include(x => x.Customer)
        .Include(x => x.Products) // 1 to many reference
        .Find(x => x.OrderDate <= DateTime.Now);

    // Each instance of Order will load Customer/Products references
    foreach(var order in query)
    {
        var name = order.Customer.Name;
        ...
    }
}