Show HN: DBMS OLTP written in Rust – prioritises clarity and correctness(github.com)

2 pointsby failsafevor 6 Monaten0 comments

Show HN: DBMS OLTP written in Rust – prioritises clarity and correctness

https://github.com/OxidizeLabs/ferrite

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.

0 comments

—