2026-06-12 22:24:52 +02:00
2026-06-12 22:23:14 +02:00
2026-06-12 22:24:52 +02:00

paulDB 🦀🏳️‍🌈

Eine eigene HTAP-Datenbank in Rust. Row- und Column-Storage in einer Engine, mit einem Delta-Merge-Konzept, inspiriert von SAP HANA. Ein Langzeitprojekt gebaut, um zu verstehen, nicht nur zu benutzen.


Was ist paulDB?

paulDB ist mein Versuch, eine Datenbank von Grund auf selbst zu schreiben in Rust. Nicht, weil die Welt noch eine Datenbank braucht, sondern weil ich wissen will, warum Datenbanken so funktionieren, wie sie funktionieren. Jede Zeile Code hier ist eine Antwort auf eine Frage, die ich mir sonst nur theoretisch beantworten könnte:

  • Wie speichert eine Engine Daten wirklich auf Platte und im Speicher?
  • Wie wird aus SELECT … WHERE … ein ausgeführter Plan?
  • Wie hält man OLTP (schnelle Einzelzugriffe) und OLAP (große Aggregationen) in einem System gleichzeitig schnell also HTAP?
  • Wie macht HANA das mit Delta und Main und kann ich das nachbauen?

paulDB ist mein „Crafting Interpreters", nur für Datenbanken.


Warum HTAP + Delta-Merge?

Klassische Systeme zwingen zur Wahl:

Optimiert für Speicherform
OLTP viele kleine Schreib-/Lesezugriffe Row-Store (Zeilen)
OLAP wenige große Aggregationen Column-Store (Spalten)

HTAP (Hybrid Transactional/Analytical Processing) will beides in einem System. SAP HANA löst das elegant über zwei Bereiche:

        Schreibzugriffe                Leseanalysen
              │                              │
              ▼                              ▼
        ┌───────────┐   Delta-Merge   ┌───────────┐
        │   DELTA   │ ───────────────▶│   MAIN    │
        │ (schreib- │   (periodisch)  │ (lese-    │
        │  optimiert)│                │ optimiert,│
        │            │                │ komprimiert)│
        └───────────┘                 └───────────┘
  • Delta: schreib-optimiert, nimmt neue Daten schnell auf.
  • Main: lese-optimiert, stark komprimiert, ideal für Analytik.
  • Delta-Merge: schiebt periodisch Delta → Main, hält Lesezugriffe schnell.

Genau dieses Prinzip ist das Herzstück von paulDB.


Architektur-Vision

┌──────────────────────────────────────────────────────┐
│                      SQL-Frontend                      │
│            Parser → AST → Planner → Optimizer          │
├──────────────────────────────────────────────────────┤
│                    Execution Engine                    │
│              (vektorisiert, wo es geht)                │
├───────────────────────────┬──────────────────────────┤
│        Row-Store          │       Column-Store        │
│      (OLTP / Delta)       │      (OLAP / Main)        │
├───────────────────────────┴──────────────────────────┤
│   Transaktionen: MVCC + WAL   │   Delta-Merge-Worker   │
├──────────────────────────────────────────────────────┤
│              Storage Layer (Pages, B-Tree)             │
└──────────────────────────────────────────────────────┘

Roadmap

Etappenweise jede Stufe ist für sich ein vollständiges Lernziel. (Reihenfolge ist Plan, kein Versprechen an einen Zeitpunkt.)

  • Etappe 0 Fundament: Rust lernen, Projektstruktur, cargo, Tests
  • Etappe 1 Storage Engine: Pages, ein einfacher B-Tree, Lesen/Schreiben auf Platte
  • Etappe 2 Row-Store + REPL: Tabellen, Zeilen einfügen/lesen, kleine SQL-Teilmenge
  • Etappe 3 SQL-Parser: Tokenizer → AST → einfacher Planner
  • Etappe 4 Transaktionen: WAL (Write-Ahead-Log), Crash-Recovery, ACID-Grundlagen
  • Etappe 5 MVCC: Multi-Version-Concurrency, mehrere Leser/Schreiber
  • Etappe 6 Column-Store: spaltige Speicherung, Kompression, vektorisierte Aggregation
  • Etappe 7 Delta-Merge: Delta + Main, periodischer Merge-Worker das HTAP-Herz ❤️
  • Etappe 8 Optimizer: Statistiken, Histogramme, kostenbasierte Planwahl

Prinzipien

  • Verstehen vor Benutzen. Jedes Modul kommentiert das Warum, nicht nur das Was.
  • Klein, aber echt. Lieber eine simple Engine, die wirklich läuft, als ein leeres Framework.
  • Analogien nutzen. paulDB ↔ Postgres ↔ HANA ↔ DuckDB Vergleiche machen Konzepte greifbar.
  • Ehrlich zum Stand. Was läuft, läuft. Was noch nicht da ist, steht offen in der Roadmap.

Lernressourcen

Die Schultern, auf denen paulDB steht:

  • 📘 Database Internals Alex Petrov (Storage Engines, B-Trees, verteilte Systeme)
  • 📗 Crafting Interpreters Robert Nystrom (Parser, AST, Interpreter fürs SQL-Frontend)
  • 💻 cstack/db_tutorial (eine simple DB Schritt für Schritt in C)
  • 🗃️ SQLite Source Code (das Vorbild für „klein, robust, vollständig")
  • 🦀 The Rust Programming Language („the Book") + Rust by Example

Status

🌱 Vision-Phase. paulDB ist aktuell ein Zuhause für einen Traum, der bewusst wartet, bis mein SAP-Fundament steht. Das ist kein Rückstand das ist Reihenfolge.

Ein leeres Repo mit klarem Plan ist kein Hochstapeln. Es ist ein Versprechen an mich selbst.


von Paul Horn · gebaut, um zu verstehen · auf dem Weg nach BC 🏔️

S
Description
Eigene HTAP-Datenbank in Rust – Row+Column Storage, Delta-Merge (HANA-inspiriert). Langzeitprojekt 🦀🏳️‍🌈
Readme MIT 64 KiB
Languages
Rust 100%