All work06 / Storage engine research

LSMSharp

Under the surface of a database.

LSMSharp is an experimental C# key-value engine built to explore log-structured merge-tree storage. It makes the relationship between buffered writes, disk-backed tables, read paths, and compaction visible in code.

Context
Personal open-source project
Engineering scope
Storage-engine implementation
Built with
C# · .NET 8 · Write-ahead logging · LSM trees
An explanatory diagram drawn from the public implementation.

01Context

Learn the system by building its parts.

A database's public API hides considerable work. Writes need a path to persistent storage; reads must find the current value across several layers; old versions eventually need to be reclaimed.

This personal engineering project examines those mechanisms directly through an embedded key-value implementation.

02Approach

Keep writes ordered, then merge.

Incoming changes enter a write-ahead log and an in-memory table. The storage path creates immutable sorted tables on disk, while the read path checks the relevant memory and disk structures.

Bloom filters help avoid unnecessary table lookups. Compaction brings older tables together and reconciles versions.

03Architecture

Memory, log, and immutable tables.

The implementation is written in C# on .NET 8. Its main mechanisms include batched WAL writes, memory tables, sorted-table storage, Bloom filters, and background compaction.

The diagram describes the source's storage flow. It is an explanation of the engine, rather than a product interface.

04Implementation

Work at the seams between layers.

The engineering interest lies in how the components coordinate, especially when a key has multiple versions across memory and disk.

Write-ahead log
Record changes in batches before they move through the storage layers.
Read filtering
Use Bloom filters to reduce unnecessary sorted-table reads.
Compaction
Merge stored tables and reconcile older values and deletion records.

05Tradeoffs

A buffered write is a deliberate boundary.

The WAL batches writes by count and time. A call can return before its batch is flushed, so an acknowledged write is not a guarantee of crash-safe persistence.

This experiment makes the durability boundary explicit: buffering groups the log writes, while persistence depends on a completed flush.

06Outcome

An inspectable storage implementation.

The public repository contains the engine, examples, and checks for key-value operations. It offers a concrete way to study the data path and its tradeoffs, with the implementation available to read and run.

Sources & further reading

A personal open-source engineering project. Experimental work, included in the team's portfolio of experience.

Next case study / 07AeroUDP

A good place to begin

What are you
building next?

A new product, a difficult system,
or a considered next step.

Start a project