KessDB is an embedded object-document database engine for .NET that stores database data in a single .kess file. It is optimized for dense Brotli-compressed storage, generated POCO codecs, and zero-copy views over decompressed pooled buffers.

KessDB - Single-File Embedded Database for .NET NativeAOT

Q: Does KessDB support NativeAOT?

KessDB is NativeAOT-oriented. It avoids runtime reflection mapping, expression-tree compilation, and dynamic code generation; typed access is emitted by a C# source generator.

Brotli chunks Independent compressed pages tuned around the 64 KiB default.

Zero-copy views Generated `readonly ref struct` views over callback-scoped spans.

Native AOT No runtime reflection mapping, expression trees, or dynamic emit.

One container `KessFormatVersion = 1` with collections, schema, indexes, and WAL.

The idea

KessDB exists for read-heavy applications that carry structured data like an asset: game definitions, rules, catalogs, pricing tables, feature packs, static reference models, and periodically refreshed edge data. The goal is to slash infrastructure footprint while keeping keyed reads fast enough to feel local to the CPU.

The product source is private. This public site exists as a technical overview for evaluation, commercial licensing, and acquisition conversations.

Up to 96.5% Footprint reduction target for highly repetitive structured datasets.

64 KiB Default chunk target chosen to balance Brotli density and lookup latency.

0 alloc Steady-state engine reads after warmed pools and non-capturing callbacks.

Where KessDB fits

KessDB is designed for teams searching for a compact .NET embedded database, a one-file object-document data container, or a NativeAOT-friendly alternative to shipping loose JSON, MessagePack blobs, SQLite tables, or service-backed reference data.

Game and simulation data Package powers, items, maps, balancing rules, modifiers, and content catalogs into one compressed `.kess` file with generated typed views.

Edge and serverless reference data Keep read-heavy lookup data local to small workers without a database daemon, connection pool, ORM, or network hop.

Embedded .NET software Use source-generated codecs and span-based reads in applications that need trim-friendly, NativeAOT-compatible local storage.

Single-file container architecture

Every release `.kess` database uses one public file-format story: a fixed header, manifest, collection directory, rich schema metadata, data chunks, optional index chunks, and an append-only WAL tail.

[KessIndexHeader]
  -> [DatabaseManifest]
  -> [CollectionDirectory...]
  -> [SchemaMetadata]
  -> [DataChunkEntry...]
  -> [IndexChunkEntry...]
  -> [Brotli Data Chunks]
  -> [Brotli Index Chunks]
  -> [WAL Tail]

Typed documents without runtime mapping Annotate a POCO with `[KessDocument]` and `[KessKey]`; the generator emits codecs, views, materializers, schema metadata, and index encoders.

Chunk mini-indexes Each decompressed data chunk contains a primary-key mini-index so records are found by binary search rather than sequential scan.

Persisted secondary indexes Index chunks hydrate immutable in-memory snapshots for equality, numeric range, string prefix, composite, and unique lookups.

Read path

Hot reads use callback-scoped spans. The caller gets a record slice only for the duration of the callback, and generated views read fields directly from that memory.

powers.WithView(42, static record =>
{
    PowerDocumentView view = new(record);
    int power = view.Power;
    ReadOnlySpan<byte> nameUtf8 = view.NameUtf8;
});

The steady-state engine read target is zero managed allocations after compressed chunks are decompressed into pooled buffers, pools and caches are warmed, and the caller uses non-capturing callbacks. Convenience materializers such as `Load`, `LoadMany`, and `LoadRange` intentionally allocate normal POCOs, strings, arrays, and lists.

Transactions and durability

KessDB uses a single-writer, multi-reader model. Writers append to the WAL and publish immutable read states. Readers merge committed WAL overlays over base chunks and do not take the writer gate.

The database payload lives in one `.kess` file. Read-write sessions may also hold a sidecar writer lease at `<database>.lock` to prevent competing writers.

Immediate mutations use automatic transactions. Explicit `KessTransaction` tokens batch writes and flush at `Commit(transaction)`. The durability contract is commit-boundary durability, not a hardware flush after every individual WAL append inside an explicit transaction.

Compaction rewrites visible base records and committed WAL overlays into fresh Brotli data and index chunks. Auto-compaction is opt-in because it can add commit latency.

Proof and diagnostics

KessDB ships with first-party proof tooling so the storage claims can be inspected instead of merely believed: validate the file, account for bytes, compact safely, salvage readable raw records, and run repeatable release workloads.

Command	Purpose
`kess validate`	Checks header, manifest, schema, chunk tables, CRCs, mini-indexes, index chunks, and WAL recovery status.
`kess stats`	Reports file-size accounting, WAL bytes, index overhead, chunk counts, and compression ratios.
`kess benchmark-smoke --canonical-v0.1`	Produces deterministic size and lookup timing data for the release profile.
`kess proof-rc`	Exercises concurrent reads, commits, deletes, compaction, reopen recovery, validation, uniqueness checks, and salvage on corrupt copies.

The benchmark path emits JSON and Markdown reports with file sizes, compression ratios, lookup timings, WAL bytes, index overhead, runtime, OS, CPU, and the exact command used.

Frequently asked questions

What is KessDB?

KessDB is an embedded object-document database engine for .NET that stores database data in one `.kess` file. It is optimized for dense Brotli-compressed storage, generated POCO codecs, and zero-copy views over decompressed pooled buffers.

Is KessDB a SQLite replacement?

No. SQLite is a mature embedded relational database with SQL and broad ecosystem support. KessDB targets a narrower workload: local keyed object-document data where the application owns the schema and wants compact storage plus fast typed reads.

Does KessDB support NativeAOT?

The architecture is NativeAOT-oriented. It avoids runtime reflection mapping, expression-tree compilation, and dynamic code generation; typed access is emitted by a C# source generator.

Why Brotli?

KessDB uses independent Brotli-compressed chunks to preserve high density while retaining random-access behavior. The default chunk target is tuned around 64 KiB to balance storage footprint and lookup latency.

Can I use this commercially?

Not without a separate written agreement. KessDB is proprietary, private-source software, not open source.

Boundaries

KessDB is not a SQL database, distributed store, MVCC engine, server daemon, or query planner. It is a specialized local object-document container for workloads that own their schema and want dense packaging with fast keyed reads.

Secondary indexes are optimized for read-heavy datasets and moderate update rates, not OLTP-style mutable B-tree workloads.

Integrity is not security. CRC validation detects accidental corruption, torn writes, and malformed files. It is not tamper resistance, encryption, signing, authenticity, or a cryptographic file-level integrity guarantee.

Licensing and commercial status

KessDB is proprietary, private-source software. This public site publishes a technical overview only. Access to product source code, private technical review materials, commercial licensing, or acquisition diligence requires a separate written agreement with the copyright owner.

The project is provided as-is for technical evaluation. There is no production support commitment, warranty, security guarantee, or service-level agreement. Commercial licensing, private evaluation terms, or acquisition discussions require a separate written agreement.