⌘
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.40
● active development
skeindb.
a single binary, two wire protocols, twenty research tracks, one author.
SkeinDB is a pre-1.0 database engine I use to study real systems design. It speaks MySQL broadly and PostgreSQL partially on the wire, ships with its own admin panel built in, and carries twenty research tracks — 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 twenty 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.40 · 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
20 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.
§
twenty research tracks
R01–R20 cover learned indexes, adaptive execution, privacy, replay, schema evolution and energy-aware maintenance. Nineteen have evidence-backed tests; Wasm query operators are still a prototype.
⌗
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 --replication/
Measured in CI on two live SkeinDB processes, September 2026 (v0.3.40). Raw reports: eval/reports. Throughput and latency benchmarks are not yet published.
compact fetch
−60%
HTTP-over-TCP bytes for a zero-overlap pull, 143,359 → 56,564 B.
CR05 · vs pre-CR05 path
binary fetch
−39%
further wire bytes at batch 32, 56,564 → 34,361 B.
CR09 · SKOF v1 body
CAS savings
86.7%
ValueStore object bytes saved, high-redundancy 300-row scenario.
two-node · 0 verify failures
second pull
0B
bytes transferred when the destination is already in sync.
idempotent · 0 connections
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 SkeinDB
1use 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// ◆ illustrative output 24// ◆ ready
F / TRACKS
ls research//
Twenty research tracks, R01–R20. Status as recorded in the repository’s TRUE_STATUS_MATRIX: hardened means covered by evidence-backed tests, not production-complete.
#namesummarystatus
01
R01ValueID lookup
Learned indexes.
hardened→02
R02execution
Adaptive row/column.
hardened→03
R03optimisation
Delta topology.
hardened→04
R04aggregates
Differential privacy.
hardened→05
R05execution
Oblivious queries.
hardened→06
R06audit
Forensic query language.
hardened→07
R07optimistic concurrency
Merge functions.
hardened→08
R08maintenance
Incremental views.
hardened→09
R09native protocol
HTTP/3 · QUIC.
hardened→10
R10first-class ValueIDs
Vector embeddings.
hardened→11
R11LLM-assisted
Semantic autoparameterisation.
hardened→12
R12with verification
NL → SkeinQL.
hardened→13
R13caching
Causal ETag chains.
hardened→14
R14replay
Edge replay bundles.
hardened→15
R15conflict-free
Schema evolution.
hardened→16
R16dependency analysis
Index synthesis.
hardened→17
R17inference
Migration intent.
hardened→18
R18cross-revision CI
Performance replay.
hardened→19
R19generated operators
Wasm query operators.
prototype→20
R20maintenance
Energy-aware compaction.
hardened→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.