diff --git a/README.md b/README.md
index 16c2804..adb552f 100644
--- a/README.md
+++ b/README.md
@@ -1,3 +1,126 @@
-# paulDB
+# paulDB 🦀🏳️‍🌈
 
-Eigene HTAP-Datenbank in Rust – Row+Column Storage, Delta-Merge (HANA-inspiriert). Langzeitprojekt 🦀🏳️‍🌈
\ No newline at end of file
+> **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](https://cstack.github.io/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.
+
+---
+
+<sub>von Paul Horn · gebaut, um zu verstehen · auf dem Weg nach BC 🏔️</sub>
\ No newline at end of file