Missverständnisse über SQLite-on-the-Server: Eher für Hyper-Scale als für kleine Umgebungen geeignet

• Viele Entwickler denken, dass der Einsatz von SQLite auf dem Server nur für kleine Anwendungen geeignet ist
• Dafür werden meist folgende Gründe genannt:
  • Niedrige Infrastrukturkosten: Kein separater Datenbankserver erforderlich (Betrieb als einzelne Datei)
  • Einfache Entwicklung und Tests: Dieselbe DB-Datei kann auf Client und Server verwendet werden
  • Minimaler Administrationsaufwand: Keine komplexe Konfiguration oder Daemon-Verwaltung nötig
  • Hohe Zuverlässigkeit: SQLite ist die weltweit am häufigsten verteilte DB und bietet starke Dauerhaftigkeit
• Tools wie LiteFS, Litestream, rqlite, Dqlite, Bedrock fügen SQLite Replikation und Hochverfügbarkeit (HA) hinzu und machen es dadurch für kleine Deployments geeignet

Dieser Artikel untersucht jedoch das Potenzial von SQLite nicht für kleine, sondern für Hyper-Scale-Anwendungen

Probleme bei der Skalierung klassischer großer Datenbanken

• Große Anwendungen setzen meist auf geshardete Datenbanken, weil sich PostgreSQL oder MySQL oft nicht als einzelne DB beibehalten lassen
• Beispiele: Cassandra, ScyllaDB, DynamoDB, Vitess (geshardetes MySQL), Citus (geshardetes Postgres)
• Geshardete DBs bieten unter anderem folgende Vorteile:
  • Optimierung von Batch Reads durch Datenpartitionierung
  • Horizontale Skalierung
  • Hohe Schreibgeschwindigkeit

Aktuelle Partitionierungslösungen haben jedoch folgende Nachteile

• Starre Schemata: Sie unterstützen keine flexiblen Abfragen wie MySQL oder Postgres
• Schemaänderungen sind schwierig: Das Hinzufügen von Indizes oder das Ändern von Relationen verursacht hohen Betriebsaufwand
• Komplexe Cross-Partition-Operationen: ACID-Transaktionen lassen sich schwer aufrechterhalten, und es sind komplexe Verfahren wie Two-Phase Commit (2PC) nötig
• Probleme mit Dateninkonsistenz: Starke Datenrestriktionen über Partitionen hinweg lassen sich schwer durchsetzen, wodurch die Datenkonsistenz leichter leidet

Das Potenzial hyper-skalierbarer Datenbanken auf SQLite-Basis

• Cloudflare Durable Objects und Turso zeigen, wie sich Hyper-Scale-Anwendungen auf Basis von SQLite entwerfen lassen
• Diese Systeme bieten folgende Stärken:
  • Dynamische Skalierung: Datenbanken werden pro Entity erzeugt, was die Infrastrukturkomplexität reduziert
  • Unbegrenzt viele kostengünstige Datenbanken: Anders als klassisches Sharding wird keine feste Datenpartitionierung erzwungen; bei Bedarf können neue SQLite-Instanzen erzeugt werden
  • Globale Verteilung: Datenbanken werden näher am Nutzer platziert, was die Performance verbessert
  • Integrierte Replikation und Dauerhaftigkeit: Anders als klassisches SQLite replizieren diese Systeme Daten über mehrere Regionen hinweg und halten so Hochverfügbarkeit aufrecht
• Ein SQLite-basierter Ansatz als Alternative zu Sharding (mit Cloudflare Durable Objects & Turso)
  • Beim klassischen Sharding werden mehrere Chat-Logs in einer einzelnen Datenbankpartition gespeichert
  • Mit SQLite kann für jeden Kanal eine eigene, unabhängige SQLite-Datenbank erzeugt werden, wodurch flexiblere Schemata möglich werden
  • Beispielstruktur
    • Klassisches Sharding: Chat-Log-Tabelle + Partitionsschlüssel
    • SQLite-basiert: separate SQLite-DB pro Kanal (inklusive Chat-Logs, Teilnehmern und Reaktionen)
• Dieser Ansatz mit SQLite bietet folgende Vorteile:
  • Lokale ACID-Transaktionen bleiben erhalten: Transaktionen können innerhalb der einzelnen DB ohne Cross-Partition-Probleme ausgeführt werden
  • Hohe I/O-Performance: Da SQLite eine Single-File-DB ist, sind Lese- und Schreibvorgänge sehr schnell
  • Nutzung von SQL-Erweiterungen möglich:
    • FTS5 (Full-Text Search): bessere Suchleistung
    • JSON1: Unterstützung für das Speichern und Abfragen von JSON-Daten
    • R*Tree, SpatiaLite: Nutzung räumlicher Daten möglich
  • Unterstützung für SQL-Migrationen: Kompatibel mit bestehenden Migrationstools wie Prisma und Drizzle
  • Unterstützung für verzögerte (Lazy) Schema-Migrationen:
    • Migrationen müssen nicht sofort ausgeführt werden; stattdessen sind leichte Migrationen beim Öffnen einer SQLite-Instanz möglich

Einschränkungen beim Einsatz von SQLite auf dem Server

• Mangel an Open-Source- und selbst hostbaren Lösungen
• Keine Unterstützung für datenbankübergreifende Abfragen → für Analysen ist ein separater Data Lake erforderlich
• Begrenztes Datenbank-Tooling (SQL-Browser, ETL-Pipelines, Monitoring, Backups)
  • StarbaseDB arbeitet daran, dieses Problem auf Basis von Cloudflare Durable Objects + SQLite zu lösen
• Fehlendes einheitliches Standardprotokoll
  • PostgreSQL, MySQL und Cassandra verwenden standardisierte Protokolle, aber SQLite-Servern fehlt bislang ein standardisiertes Netzwerkprotokoll
• Zu wenige groß angelegte Praxisbeispiele für SQLite im Hyper-Scale-Bereich
  • Es gibt noch zu wenige Fallstudien wie bei Cassandra oder DynamoDB, doch das könnte sich mit der Zeit ändern

Fazit: SQLite ist nicht nur eine einfache lokale DB, sondern auch für Hyper-Scale-Anwendungen eine starke Option

• SQLite ist nicht nur eine DB für kleine Projekte, sondern auch ein leistungsfähiges Werkzeug, das in Hyper-Scale-Anwendungen klassische Sharding-Ansätze ersetzen kann
• Mit Cloudflare Durable Objects & Turso lassen sich Datenbanken auf Entity-Ebene aufteilen und gleichzeitig die Stärken von SQL sowie ACID-Transaktionen beim Skalieren erhalten
• Es hat großes Potenzial, sich als flexiblere und leichter zu verwaltende Alternative zu traditionellen geshardeten Datenbanken zu etablieren

[pcj9024]

Wer mutig genug ist, SQLite in einer Hyper-Scale-Umgebung mit sehr vielen Anfragen einzusetzen ...

[GN⁺]

Hacker-News-Kommentare

• Ein Nutzer überlegt, eine Custom-Datenbank durch eine SQL-Datenbank zu ersetzen

  • Sqlite3 kommt als Kandidat infrage, da es auf einem einzelnen Server läuft
  • Die Datenbank ist überwiegend leseintensiv, wodurch Sqlite3 im Vorteil ist
  • Die Custom-Datenbank ist bei bestimmten Aufgaben sehr schnell, aber die Entscheidung ist komplex
  • Per Benchmark wurden Sqlite3 und Postgresql verglichen
  • Sqlite3 war bei allen Aufgaben etwa doppelt so schnell wie Postgresql
  • Die Custom-Datenbank ist beim Zugriff auf einzelne Records 100- bis 1.000-mal schneller als Sqlite3

• Ein Nutzer entwickelt eine Local-First-Web-App und hält SQLite für passend

  • Er sucht nach einer einfachen Möglichkeit, den Zustand einer SQLite-Datenbank mit einem Cloud-Service zu synchronisieren
  • Turso und SQLite Cloud wirken wie vielversprechende Optionen
  • Er erwägt einen einfachen Ansatz, bei dem Nutzer auf S3-Storage pushen können

• Es wird über die Vorteile von SQLite-per-Partition diskutiert

  • In Situationen, in denen globale Tabellen nötig sind, gibt es Grenzen
  • Verschiedene Projekterfahrungen mit SQLite werden geteilt

• In Multi-User-Umgebungen stößt SQLite wegen des fehlenden MVCC auf Schwierigkeiten

  • Es wird nach SQLite-kompatiblen Implementierungen und Erweiterungen gefragt, die MVCC hinzufügen

• Mit dem Release 8.0 von Ruby on Rails wurde die SQLite-Unterstützung erweitert

  • Dadurch werden Cache- und Job-Queue-Komponenten ersetzt und es wird für typische Web-Apps geeignet

• Ein Nutzer, der mit Vitess oder Citus nicht vertraut ist, hat Schwierigkeiten, den Inhalt des Artikels zu verstehen

  • Er fragt sich nach dem Unterschied zwischen Sharded Sqlite und Sharded Postgres

• Ein Nutzer wollte kein VPS-Hosting und baute deshalb eine Webseite mit SQLite

  • Die Datenbank wird zur Nutzung auf das Gerät des Nutzers heruntergeladen

• Ein Nutzer, der Schwierigkeiten beim Einrichten eines Ubiquiti-Controllers hatte, schlägt den Einsatz von SQLite vor

  • Er meint, dass SQLite statt MongoDB eine bessere Erfahrung bieten könnte

• Apple betreibt Stand 2022 rund 300.000 Cassandra-/ScyllaDB-Instanzen

  • Der Ansatz DB-per-Tenant wird als der bessere Weg nach vorn bewertet

• TDLib (Telegram Database Library) verwendet SQLite

  • Jede TDLib-Instanz verarbeitet gleichzeitig mehr als 24.000 aktive Bots