.kess artifact.
Strategic Position
KessDB exists for structured data carried like an application asset: game definition files, catalog trees, rules, pricing tables, localization indexes, static reference models, and periodically refreshed edge data. It prioritizes predictable keyed object access and compact file layout over generalized relational query processing.
The product source is private. This site functions as a public technical overview for workload-fit screening, architectural planning, and commercial licensing conversations. Detailed physical format review belongs in a private diligence package.
Target Workloads
The system is optimized for applications that own their schema, know their access patterns, and want compact local storage with fast typed reads. The optional network layer is a deployment shape, not the identity of the database.
.kess package.
.kess deployment model.
Single-File Container & Ahead-of-Time Access
KessDB packages typed collections, schema metadata, compressed record pages, optional lookup structures, and recovery metadata into one release-format .kess container. Generated codecs provide typed access paths so the primary read path does not depend on runtime reflection mapping.
Application Models → Generated Typed Access → .kess Container → Validated Keyed Reads
Controlled Sidecar Deployment
For out-of-process topologies, KessDB can run behind a controlled client boundary. The public site should describe the deployment shape and security posture without publishing frame constants, offset tables, operation ids, or binary dispatch details.
Application → KessDB Client Boundary → Authenticated Channel → Sidecar Process → .kess Container
Public Performance Snapshot
Storage-engine and sidecar measurements are separated so storage density, local access behavior, and deployment overhead remain easy to evaluate. Public benchmark summaries preserve the headline evidence while withholding exact harness arguments, internal build identifiers, and proprietary format details.
Storage Engine Compression Scale
Storage workloads run without the sidecar layer and process a private representative object-document corpus. Detailed corpus shape, exact harness arguments, and reproduction appendices belong in private evaluation material; the linked summaries are intentionally sanitized.
| Pass Profile Name | Evidence | Hot Delta Save | Full-Fidelity Save | Target Archive Size | Compaction Runtime | Validation State | Run Profile |
|---|---|---|---|---|---|---|---|
| Sequential Baseline | Public sequential summary |
554.96 ms | 1.670 s | 38,073,370 B | 1.447 s | clean |
Sequential local baseline |
| Parallel Optimized | Public parallel summary |
507.84 ms | 1.176 s | 38,073,370 B | 898.82 ms | clean |
Parallel local profile |
Optional Network Loopback Performance
Sidecar benchmarks are measured separately over local transport so deployment overhead remains visible without publishing protocol framing, binary message layout, or dispatch constants.
| Security Mode | Evidence | Session Handshake Time | Point Read Latency (p50 / p95 / p99) | Index Read Latency (p50 / p95 / p99) | Total Throughput | Heap Allocation Tax |
|---|---|---|---|---|---|---|
| Plaintext Loopback | Public loopback summary |
8,858.80 us | 58.30 / 65.60 / 90.40 us | 58.70 / 70.30 / 110.10 us | 17,152 Ops/sec | 0.00 B / Read Operation |
| TLS 1.3 Secure Link | Public loopback summary |
21,173.60 us | 64.60 / 72.50 / 95.80 us | 62.20 / 70.10 / 90.10 us | 15,479 Ops/sec | 0.00 B / Read Operation |
| mTLS / TLS 1.3 Dual-Auth | Public loopback summary |
36,796.70 us | 62.00 / 66.70 / 83.20 us | 62.70 / 66.90 / 85.40 us | 16,129 Ops/sec | 0.00 B / Read Operation |
0.00 B of steady-state engine allocations after buffers and caches are warmed. Convenience materializers intentionally allocate ordinary managed objects.
Typed Access Model
The public story should explain the access model without publishing exact API signatures, collection identifiers, binary constants, or sample domain models from private datasets.
Native Runtime Roadmap
A native C++ wrapper is planned so C++ applications and engine integrations can consume .kess containers through a native-friendly API.
The wrapper is intended to expose KessDB read-oriented access patterns to native callers without creating a second database format. The core implementation remains proprietary and is scoped through private technical review.
Frequently Asked Questions
What exactly is KessDB?
KessDB is a proprietary embedded object-document database engine for read-heavy .NET workloads. It packages typed data into one .kess file and uses generated typed access paths to support compact, predictable keyed reads.
Is this meant to replace SQLite instances?
No. SQLite is a mature embedded relational database with SQL, ad hoc queries, transactions, and broad ecosystem support. KessDB targets a narrower shape: keyed object-document data where the application owns the schema and wants compact storage plus fast typed reads.
How does it interface with NativeAOT builds?
The typed storage path avoids runtime reflection-based mapping in the primary access path. A C# source generator emits the typed access code needed for known application models.
Engine Boundaries
KessDB is specialized systems software. It deliberately excludes SQL, ad hoc query planning, server-side distributed replication, multi-writer concurrency, foreign-key joins, and general LINQ or predicate translation.
Secondary lookup structures are optimized for read-heavy datasets and moderate update rates, not generalized OLTP-style mutable indexing workloads.
Diligence & Licensing Evaluation
KessDB is private, proprietary software. This public overview is published for architectural planning, workload-fit review, commercial diligence, and licensing evaluation. Source access, prototype binaries, implementation details, and commercial distribution terms require a separate written agreement with the copyright holder.