⌘
single binary, no daemons
Engine, wire protocols, admin UI, telemetry, Wasm runtime — all link into one executable. Laptop, Pi, bare VM — no compose file, no sidecars.
research
v0.3.17
● active · shipping weekly
skeindb.
a single binary, two wire protocols, fourteen research tracks, one author.
SkeinDB is a teaching database engine that also runs production. It speaks MySQL and PostgreSQL on the wire, ships with its own admin panel built in, and exposes fourteen hardened research surfaces — from MVCC reclamation to sandboxed Wasm extensions — so you can study real systems without losing the thread.
A / ABSTRACT
cat README.md/
The five-minute version. What & why.
Abstract · 2026
Most production database engines hide their interesting choices behind layers of operations sprawl: separate sidecars for the admin panel, separate processes for replication, separate teams for everything else. SkeinDB compresses that down to one binary, two wire protocols, and a control surface you can read in an afternoon.
It exists so I — and anyone reading the source — can study real database behavior without a docker-compose file. The fourteen research tracks aren't marketing checkboxes; they're each instrumented, benchmarked, and discussed in companion notes. Wasm extensions let third parties experiment without rebuilding the engine.
database enginerustMVCCwire compatwasm extteaching systemsingle binary
B / ARCHITECTURE
tree -L 2/
One binary, drawn out. Each box is replaceable, each is instrumented.
fig.01 · architecture
skeindb v0.3.17 · one binary
data ↘ storage
control ↗ admin
clients
mysql · psql · ORMs
unmodified drivers
clients
SkeinAdmin UI
embedded HTTP
wire
MySQL · Postgres
protocol shim · single port
core
dispatcher
router · session · txn
extensions
Wasm sandbox
user fns · isolated
control
SkeinAdmin
14 research tracks
engine
planner / executor
MVCC · vectorized
storage
page heap + LSM
crash-safe · WAL
telemetry
/metrics + traces
native OTLP
C / FEATURES
ls features/
Six things that make it different from another rust DB toy.
↔
mysql and postgres, one port
Protocol shim sniffs the handshake and routes accordingly. Your existing ORM, your existing CLI, your existing dashboards — nothing on the client knows.
§
fourteen research tracks
Each is a hardened path: optimistic vs pessimistic MVCC, vectorized vs row-at-a-time, LSM vs page-heap. Pick one, bench it, read the notes.
⌗
SkeinAdmin — built in
Not a separate service. Same binary, same Axum router, same auth, same logs, same lifecycle. Bind to the port you want.
∞
sandboxed wasm extensions
User-defined functions in a capability-restricted Wasm sandbox. No arbitrary FS or net — extension authors get a typed handle to the row stream.
◐
crash-safe by default
Group-commit WAL, fsync barriers, deterministic recovery, startup verification pass. You opt out of safety, not in.
D / NUMBERS
bench --release/
2024 M2 Pro, 16GB. Reproducible — scripts in /bench. No tuning beyond defaults.
cold start
88ms
from
./skeindb to first query accepted.Δ vs mysqld: −94%
binary size
27mb
engine + admin + 2 wires + wasm.
stripped · release · LTO
TPC-C / min
42k
tpmC at scale 10 · MVCC track.
m2 pro · single socket
p99 latency
2.4ms
key lookups, hot dataset, full WAL durability.
99th pct · 10M req
E / INTERFACE
cat src/main.rs/
It feels like any other DB. That's the point.
one connection string · two protocols
Point your existing tooling at SkeinDB — mysql://, postgres://, doesn't matter. The wire shim picks up the handshake, the dispatcher routes the parsed statement to the same planner, you get the same row stream back.
This is what makes it useful as a teaching engine: the surface is familiar, but you can pop the hood any time and read what just happened in /admin/explain or /admin/trace.
port
3306 · 5432 · single bind
auth
mTLS · SCRAM · token
drivers
any standard mysql/pgx client
admin
:9001 · same binary
src/main.rs · embed SkeinDB1use skeindb::{Server, Config, Wire}; 2 3// one binary. two protocols. no sidecars. 4#[tokio::main] 5async fn main() -> Result<()> { 6 let cfg = Config::load("./skeindb.toml")?; 7 8 Server::builder() 9 .wire(Wire::Mysql) // 3306 10 .wire(Wire::Postgres) // 5432 11 .admin("127.0.0.1:9001") // embedded UI 12 .track("mvcc.reclaim_v2") // 1 of 14 13 .extension("./udf/cosine.wasm") 14 .durability(Durability::FsyncEach) 15 .build(cfg)? 16 .run() 17 .await 18} 19 20// $ ./skeindb 21// ◆ wire: mysql:3306, postgres:5432 22// ◆ admin: http://127.0.0.1:9001 23// ◆ track: mvcc.reclaim_v2 [active] 24// ◆ ready in 88ms
F / TRACKS
ls research//
Fourteen real paths through the engine. Each has notes. Each has a bench.
#namesummarystatus
01
mvcc.opt_pessvisibility regimes
Optimistic and pessimistic MVCC sharing a planner; switchable per connection.
stable→02
mvcc.reclaim_v2generation tombstones
Bounded wall-clock recovery; reclamation pass is the active work item.
beta→03
exec.vectorizedmorsel-driven
SIMD-friendly columnar interior; same plan tree as the row executor.
stable→04
exec.row_at_a_timeteaching mode
Legacy walker for the same plan tree. Used when explaining join algorithms.
stable→05
storage.page_heapB+tree COW
Copy-on-write pages with group commit. Default storage.
stable→06
storage.lsmtiered compaction
Bloom-tuned for write-heavy workloads. Alternate storage.
beta→07
plan.cachehash-stable
Parameterized plan reuse with hash-stable identity across sessions.
stable→08
plan.cost_basedstatistics
Cost-based optimizer with explainable cost dumps; in revision.
beta→09
wire.mysqlprotocol shim
Compatible with mysql, mariadb, planetscale clients.
stable→10
wire.postgreslibpq compatible
SCRAM, prepared statements, copy-from.
stable→11
ext.wasmcapability-restricted
UDFs with typed row bindings. No FS, no net by default.
beta→12
telemetry.otlpnative exporter
Spans, metrics, logs from one /telemetry endpoint.
stable→13
replication.det_loghash-chained WAL
Deterministic log stream for verifiable followers.
draft→14
recovery.verifystartup proof
Verification pass that proves recovery converged; runs on every boot.
stable→G / ROADMAP
git log --quarters/
Six quarters. Honest about what's shipped vs shipping.
Q4 · 2024
first binary; mysql wire
page-heap storage
manual recovery
Q1 · 2025
postgres wire shim
SkeinAdmin v1
OTLP telemetry
Q2 · 2025
MVCC v1
vectorized executor
first 7 tracks docd
Q3 · 2025
plan cache
LSM storage beta
wasm ext v0
Q2 · 2026 — now
MVCC reclaim v2
cost-based optimizer
engine handbook draft
Q4 · 2026
deterministic replication
1.0 cut · stability promise
all 14 tracks stable
H / PAPER
man paper/
Separate research thread from the same workstation.
separate paper · IJRC 2026
adjacent cyber-risk work, not a SkeinDB paper
Computational Knightian Uncertainty belongs to my cyber-risk quantification research line. It is included here as adjacent reading from the broader workstation, not as a foundation or companion paper for SkeinDB.
▸ read on IJRCCite as — copy the BibTeX block. Also indexed on Scholar.
@article{nguyen2026cku, title = {Computational Knightian Uncertainty: Undecidability and the Limits of Cyber Risk Quantification in Software-Intensive Firms}, author = {Nguyen, Mich\'el}, journal= {Intl. J. of Research in Computing}, year = {2026}, month = {jan}, url = {https://www.ijrcom.org/.../192}, }
I / FAQ
cat faq.md/
The four questions I get most often. Honest answers.
q · 01
is it production-ready?
Pre-1.0. I run it for my own services. I would not run it as a system of record for someone else's payments. Stable tracks are reliable; beta and draft tracks change shape without warning. 1.0 is targeted for Q4 2026 with a written stability commitment.
q · 02
why not just fork postgres?
Because the goal isn't a faster Postgres — it's a database you can read end-to-end in a weekend. Forks inherit thirty years of incidental complexity. SkeinDB is built so the planner, executor, and storage layer each fit in one head.
q · 03
can i use it in a class / lab?
Yes, and please do. The engine handbook is being written specifically for that case. Reach out — I'm happy to walk through a track with anyone teaching from it.