| 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 levelsIndexes: * 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 roadmapThis “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.
|