Show HN: DBMS OLTP written in Rust – prioritises clarity and correctness
by failsafe | 2026-01-06 11:36:59+00:00
Hi HN,

I want to share Ferrite, an open-source OLTP database engine written in Rust that prioritizes clarity, correctness, and modern concurrency design over chasing feature-completeness or benchmark wars.

Ferrite is not trying to be a drop-in replacement for Postgres or SQLite. Instead, it’s designed as:

The smallest, clearest, well-documented OLTP engine showing how ACID, recovery, and concurrency work internally.

A learning and experimentation platform with code you can reason about

A solid foundation for future academic or production-grade work

PS it's my first HN post, so I hope you enjoy it and go easy on me.

Check it out here:
https://github.com/OxidizeLabs/ferrite

Why I Built Ferrite

Most DBMS systems today:

* Hide internals under complex codebases
* Accrue decades of legacy design decisions
* Make it hard to see exactly how correctness is achieved, especially in Rust
* Mix distribution, analytics, and OLTP orthogonally

Ferrite’s focus is pure OLTP, with readable code, tight documentation, and reproducible demonstrations of key DBMS concepts like concurrency control and ARIES-style crash recovery.

Core Capabilities:

Ferrite implements a traditional layered DB architecture with:

Storage & Recovery:

* Write-Ahead Logging with ARIES-style recovery semantics
* Buffer pool with an LRU-K replacement policy

Concurrency & Transactions
* Two-phase locking with deadlock detection
* ACID transactions with multiple isolation levels

Indexes:

* B+ Tree indexes with latch crabbing for safe concurrent access

SQL Support:

* DDL/DML, queries with joins, aggregations, and some window functions

All implemented in Rust, with safety and minimal unsafe code.

Technical Highlights:

* Memory safety by default (Rust) with minimal unsafe code
* Async I/O via Tokio, enabling backpressure and non-blocking execution
* Hybrid deployment modes: use Ferrite as an embedded library or in client-server mode
* Explicit documentation: architecture diagrams, module descriptions, and evidence of correctness

What It’s Not:

Ferrite deliberately doesn’t (yet):

* Aim for full Postgres/SQLite compatibility
* Support distributed consensus
* Try to chase every benchmark out there

Fully complete SQL features — some are planned for the roadmap

This “non-goals-first” clarity helps keep the codebase approachable and educational.

Some Background

It all started with CMU 15–445 Introduction to Database Systems – https://15445.courses.cs.cmu.edu/spring2026/,
a brilliant course for those wanting to learn about DBMS internals (so mucho gracias Andy Pavlo and Jignesh Patel).

They had built BUSTUB for the course as a way for students to use as a learning tool, but it was written in C++ and I wanted to try Rust.
At first It was just going to be a learning project, the company I was working for was being taken over, and in the chaos,
I had some extra time on my hands, and then LLM started to get really good, so I decided to try and extend the project to something akin to a real DBMS.

Then I got made redundant and had a lot of time on my hands, so the project got a lot more ambitious. A lot of the code was written by LLMs, with myself acting more as an architect, with some fixes by myself.
So if anything, it can act as a demonstration of how much a single person can output with current LLM (for better or worse).

Some Caveats:

* The project is in a "just about working" state, and I'm not planning on adding any new features.
* The code is not optimized for performance, although the caching layer is probably too complex for the projects aims.
* as many tests were written by LLMs, I expect many of them to be utter garbage, so, I need to go through them and clean them up.