Weg A oder Weg B — SQLite oder PostgreSQL?

Cyber Panda Psychologe

Du baust eine neue Anwendung und musst dich für eine Datenbank entscheiden. Die einfachste Variante liegt direkt in der Tasche: SQLite. Die Profi-Variante läuft als eigener Prozess: PostgreSQL. Wo liegt der Unterschied, und was passt zu deinem Projekt?

Weg A: SQLite

SQLite ist die embedded Datenbank, die in jeder Anwendung mitgeliefert wird. Kein separates Binary, kein Daemon, kein Konfigurationsaufwand. Du öffnest eine Datei, führst SQL aus — fertig.

Vorteile:

  • Zero-Config: kein Server, kein Port, kein Connection-Pooling
  • Perfekt für Single-Node-Anwendungen und lokale Tools
  • Datenbank ist eine einzelne Datei — Backup ist ein cp
  • Schnell für Leseoperationen, besonders bei kleinen bis mittleren Datensätzen

Nachteile:

  • Kein echtes Multi-Writer-Szenario: concurrent writes werden serialisiert, bei hohem Write-Aufkommen wird es eng
  • Kein Netzwerkzugriff von Haus aus — jeder Client muss physischen Zugriff auf die Datei haben
  • Tooling für Monitoring, Replication und Clustering existiert nicht oder nur als Drittanbieter-Lösungen

Ideal für: CLI-Tools, Desktop-Anwendungen, kleine Web-Apps mit wenigen tausend Requests pro Tag, IoT-Edge-Geräte, Prototypen.

Weg B: PostgreSQL

PostgreSQL ist der bewährte Open-Source-Datenbankserver. Er läuft als separates System, wartet auf Port 5432 und spricht SQL mit Features, die man in anderen Systemen vergeblich sucht.

Vorteile:

  • Echtes Client-Server-Modell mit Netzwerkzugriff
  • ACID-konform, MVCC, komplexe Transaktionen, Replication, Point-in-Time-Recovery
  • Erweiterbarkeit: PostGIS für Geodaten, pgvector für Vektorsuche, JSONB für NoSQL-Style-Dokumente — alles in einer Datenbank
  • Reifes Ökosystem: Admin-Tools, Monitoring, ORMs, Backup-Strategien

Nachteile:

  • Deutlich höherer Operationsaufwand: Installation, Konfiguration, Wartung, Backups, Updates
  • Für einfache Anwendungen oft Overkill — wie einen LKW zu mieten, um einen Brief zu verschicken
  • Ressourcenhungrig: RAM, CPU, Disk-IO müssen geplant werden

Ideal für: Webanwendungen mit mehreren Servern, Multi-User-Systeme, Datenbanken mit komplexen Beziehungen, analytische Workloads, Systeme, die Replication und Hochverfügbarkeit benötigen.

Direkter Vergleich

  • Setup: SQLite — Datei erstellen, loslegen. PostgreSQL — Server installieren, initdb, pg_ctl starten, Nutzer anlegen, Firewall konfigurieren.
  • Concurrency: SQLite — eine Schreiboperation gleichzeitig (bei Write-Ahead-Logging etwas entspannter, aber immer noch limitiert). PostgreSQL — tausende gleichzeitige Connections mit Proper Locking.
  • Backup: SQLite — Datei kopieren, solange keine Schreiboperation läuft. PostgreSQL — pg_dump, continuous archiving, WAL-Replication.
  • Features: SQLite — solides SQL mit allen Grundfunktionen. PostgreSQL — Transaktionen, Views, Stored Procedures, Erweiterungen für fast jeden Anwendungsfall.
  • Tooling: SQLite — sqlite3 CLI, wenige GUI-Tools. PostgreSQL — pgAdmin, psql, DBeaver, Prometheus-Exporter, unzählige ORMs mit vollem Feature-Support.
  • Skalierung: SQLite — vertikal auf dem einzelnen Host, Sharding nur manuell. PostgreSQL — Replication, Read Replicas, Partitionierung, Foreign Data Wrappers.

Fazit

Die Frage ist nicht, welche Datenbank “besser” ist. Die Frage ist, was deine Anwendung heute braucht und in 18 Monaten brauchen wird.

SQLite ist kein Spielzeug — es ist eine vollwertige SQL-Engine, die in Millionen von Anwendungen läuft, von iPhones bis zu Browsern. Aber sobald du echte Multi-User-Concurrency, Replication oder erweiterte SQL-Features brauchst, wächst SQLite über seinen Sweet Spot hinaus.

PostgreSQL ist der Standard für einen Grund: Es funktioniert, es skaliert, es hat alles. Aber für ein kleines Tool oder eine lokale Anwendung ist es wie einen Webserver zu mieten, der nur eine statische Seite ausliefert.

Welchen Weg gehst du?