Am 11. Juli 2026 tat eine Website namens Lobsters etwas, das zunächst widersinnig klingt: Sie ersetzte das seit über zehn Jahren genutzte kostenpflichtige Datenbanksystem (eine kommerzielle Software namens MariaDB, für die man einen eigenen Server mieten musste) durch eine völlig kostenlose Datenbank – SQLite. Man kann sich Letzteres als 「Datei-Datenbank」 vorstellen: kein separater Server, keine extra Rechnung, mit ein paar Zeilen Code am Laufen.
Zwei Tage später, an einem Montagmorgen, schrieb einer der Betreuer im internen Thread: Die CPU-Auslastung sank, der Speicherverbrauch sank, die Seiten luden flüssiger. Der entscheidende Satz: 「Sobald der MariaDB-Server komplett abgeschaltet ist, halbiert sich die monatliche VPS-Rechnung direkt.」
In der Programmierer-Szene schlug der Posting ein. 384 Likes, 92 Kommentare. Nicht, weil die Technik besonders beeindruckend gewesen wäre – im Gegenteil, gerade weil die Sache so schlicht war.
Eine sieben Jahre lange Datenbank-Zerrissenheit
Bevor wir von dieser Migration erzählen, kurz, was Lobsters ist. Es ist eine 「Link-Sharing-plus-Diskussion」-Website für Programmierer, sozusagen ein ruhigeres, härteres Hacker News. Nutzer teilen dort technische Artikel, andere stimmen ab und kommentieren. Die Seite ist klein – die Datenbankdatei ist etwa 500 MB groß, der Alltagsverkehr bewältigt ein gewöhnlicher Server –, aber sie läuft seit über zehn Jahren stabil.
Das Problem lag in der genutzten Datenbank. Früher entschied sich Lobsters für MariaDB – ein kommerzielles Datenbanksystem, das einen eigenen Server erfordert. Mit der Zeit fand das Team die Lösung zu schwer: Ein zusätzlicher Server bedeutet eine extra Monatsrechnung und einen weiteren potenziellen Ausfallpunkt, der gewartet werden muss. Im August 2018 eröffnete der Hauptbetreuer pushcx auf GitHub eine Diskussion mit dem Titel 「Diskussion über Migration zu PostgreSQL」 – einer weiteren kostenpflichtigen Datenbank.
Der Thread lag sieben Jahre lang brach, wobei die Richtung von PostgreSQL zu SQLite driftete. Die echte Wende kam Anfang 2025: Die Investmentgruppe K1 übernahm MariaDB, was der Community Zweifel an MariaDBs langfristiger Zukunft einflößte. Gleichzeitig fragte ein Community-Mitglied namens Rahul im Thread: 「Kann Lobsters auf SQLite laufen?」
Was ist SQLite? In einem Satz: eine kostenlose Datenbank, die alle Daten in einer lokalen Datei speichert. Keine Installation, keine Konfiguration, kein separater Server. Sie steckt im Chrome-Browser, in WeChat, in jeder App auf eurem Handy – es ist die meistinstallierte Datenbank-Engine der Welt. Aber lange galt sie als 「für Websites ungeeignet」, weil ihr Design anders denkt als herkömmliche, einen eigenen Server benötigende Datenbanksysteme (MariaDB, PostgreSQL, MySQL).
Rahuls Frage stieß diese stillschweigende Annahme um.
Erster Migrationsversuch: CPU sprengte auf 100 %, Notfall-Rollback
Im Juni 2025 übernahm ein Community-Mitwirkender namens thomas0 offiziell die Migrationsarbeit. In seinem Posting hielt er ein selten offenes Selbstbekenntnis fest: Der gesamte Prozess umfasste drei Code-Commit-Versuche, einen gescheiterten Go-Live und dann die Korrektur von drei Problemen, bevor es endlich klappte.
Der erste Go-Live fand am 21. Februar 2026 statt. thomas0 und pushcx telefonierten und erstellten eine detaillierte Bereitstellungs-Checkliste; alles lief nach Plan – bis der neue Code live ging. Die Seite wechselte in den Nur-Lese-Modus (eine Schutzmaßnahme, um Datenverlust bei Schreibvorgängen zu verhindern), aber allein durch die Bearbeitung der Leseanfragen der Nutzer wurde die gesamte CPU auf 100 % getrieben. Abgestürzt. Die beiden suchten eine halbe Ewigkeit nach der Ursache, fanden keine. Entscheidung: Rollback.
thomas0 schrieb im Posting: 「Nach diesem Fehlschlag fühlte ich mich nicht gut.」 Denn er hatte im Vorfeld schon gewusst, dass ohne Zugriff auf die Produktionsdatenbank Leistungsprobleme ein Risiko sein könnten – und seine Vermutung bestätigte sich.
Bei der Nachbesprechung kristallisierten sich drei Ursachen heraus. Zwei davon: SQLite führte bei den zwei größten Tabellen der Datenbank einen 「Full Table Scan」 durch – als würde man in einer Bibliothek ein Buch suchen, indem man das erste Regal von vorne bis hinten durchblättert, statt über den Katalog die Nummer nachzuschlagen. Bei wenig Daten kein Problem, bei vielen Daten aber musste der Server bei jedem Seitenaufruf die ganze Tabelle von vorne bis hinten lesen – die CPU war sofort am Anschlag. Die dritte Ursache war ein ineffizientes Muster namens 「N+1-Query」: Bei jeder abgefragten Datensatz schickte das Programm nochmals N extra Abfragen los. Richtig wäre gewesen, die benötigten Daten auf einmal zu holen.
Drei Probleme, zwei im SQL-Code, eines in der Programmlogik. Keines davon war ein Fehler von SQLite selbst – es war vielmehr so, dass derselbe Code auf zwei unterschiedlichen Datenbanksystemen völlig verschiedene Ausführungseffizienzen erzeugt.
Zweite Migration: Ein ruhiger Montagmorgen
Nach dem Rollback vom 21. Februar reichte thomas0 schon zwei Tage später die dritte Korrektur ein. Was hatte er gemacht?
Zunächst behob er die beiden Full-Table-Scan-Probleme aus dem ersten Go-Live: Er setzte passende Indizes auf die Abfragen – das entspricht einem schnellen Suchkatalog für jene 「großen Tabellen」. Für Datenbankkundige ist das Basiswissen; im Migrationskontext liegt der Knackpunkt darin: Auf MariaDB liefen diese Abfragen möglicherweise über andere Ausführungspfade, weshalb das Leistungsproblem nie zutage trat. Auf SQLite wählte dieselbe Abfrage eine andere Strategie – den Vollscan. Datenbank gewechselt, und aus dem ehemals 「guten Code」 wurde 「schlechter Code」.
Zweitens reparierte er das N+1-Query: Aus der Schleifenabfrage wurde eine Batch-Abfrage. Das Programm fragte die Datenbank nicht mehr einzeln, sondern holte alles Benötigte auf einmal.
Drittens verbrachte er eine Woche damit, mit einem selbst geschriebenen Skript lokal Testdaten in Halbgröße der echten Lobsters-Datenmenge zu erzeugen – da er nicht an die echten Produktionsdaten kam, musste er den Traffic so simulieren. Schon dieses Skript war ein extra Engineering-Aufwand.
Viertens baute er zur Sicherheit vor dem Go-Live einen Schalter für ein 「Slow-Query-Log」 ein: Sollte es noch unentdeckte Leistungsprobleme geben, zeichnet das System automatisch alle Abfragen auf, die länger als 100 Millisekunden dauern, damit man sie schnell orten kann.
Am 11. Juli 2026 der zweite Go-Live. Diesmal endete es anders. Die Seite lief normal weiter, CPU- und Speicherkurven blieben ruhig. Im Chat-Kanal verfolgten sie die Nutzerfeedback, bearbeiteten zwei kleine Probleme und warteten dann auf den Montag – die eigentliche Belastungsprobe durch den Traffic-Gipfel.
Montagvormittag: alles friedlich. pushcx schrieb im internen Chat: 「Wir hatten einen ruhigen Montag.」
Warum eine 「einfachere」 Datenbank eigentlich besser ist
Der widersinnige Kern dieser Geschichte liegt hier: SQLite ist viel 「schlichter」 als MariaDB – kein Benutzerberechtigungssystem, keine Unterstützung für massenhafte gleichzeitige Schreibvorgänge, kein Netzwerk-Remote-Zugriff, viele fortgeschrittene Abfragesyntaxen fehlen. Und doch lief bei Lobsters nach dem Wechsel alles besser.
Dafür gibt es drei Gründe.
Erste Ebene: Ein Server weniger, eine Menge Ärger weniger. In der alten Architektur lief die Lobsters-Web-App auf einem Server, die MariaDB-Datenbank auf einem anderen. Zwischen den beiden Maschinen war Netzwerkkommunikation nötig, sie mussten separat gewartet, separat gesichert, separat überwacht werden. SQLite verwandelte die Datenbank in eine Datei innerhalb der Web-App – die Daten liegen auf demselben Rechner, die Sicherung ist das Kopieren einer Datei. Für eine Website wie Lobsters, die 「mit einem Server den gesamten Traffic bewältigen kann」, ist ein eigenständiger Datenbankserver kein Asset, sondern eine Last.
Zweite Ebene: Latenz eliminieren. Bei jedem Seitenaufruf muss die Web-App die Datenbank abfragen. In der MariaDB-Architektur ging diese Abfrage den Weg 「App → Netzwerk → Datenbankserver → Netzwerk → App」 hin und zurück. Mit SQLite wurde die Abfrage zu 「App → lokale Datei」 – die Netzwerklatenz als Variable fiel komplett weg. Für leselastige Websites – etwa eine Link-Sharing-Seite – ist die dadurch gewonnene Reaktionsgeschwindigkeit spürbar.
Dritte Ebene: Kosten. Das ist am greifbarsten. Die monatliche Miete für den MariaDB-Server entfällt jetzt. Die VPS-Kosten halbieren sich direkt. Das ist kein abstraktes 「Kostenoptimierung」, sondern eine fehlende Ziffer auf der Rechnung.
thomas0 listete im Posting noch einige technische Details auf: SQLite unterstützt keine vorzeichenlosen großen Ganzzahlen, weshalb die Typen mancher ID-Felder geändert werden mussten; SQLite hat eine schwächere Sortierreihenfolge als MariaDB, unterstützt nur ASCII-Groß-/Kleinschreibung-Ignoranz, nicht die volle UTF-8-Schreibweise; er nutzte benutzerdefinierte Funktionen, um einige bei SQLite fehlende Rechenfunktionen zu ergänzen. Diese Details sind für Normalleser unwichtig, aber sie verdeutlichen eines: Das Wesen einer Migration besteht darin, zwischen zwei Systemen einen neuen Satz Pfade zu finden, auf denen alle Funktionen weiterhin arbeiten.
「Gut genug」 und die 「Komplexitätsverehrung」 der Softwarebranche
Der Grund, warum diese Geschichte einem breiteren Publikum erzählt werden sollte, liegt nicht auf der technischen Ebene. Sie berührt eine tief verwurzelte Gewohnheit der Softwarebranche: standardmäßig die 「große, volle」 Lösung zu wählen, statt der 「ausreichenden」.
Lobsters wählte anfangs MariaDB, weil damals der Standard für Webseiten 「Anwendung plus eigenständiger Datenbankserver」 lautete. Diese Architektur war vor über zehn Jahren vernünftig – damals waren hohe Wachstumserwartungen, starke Traffic-Schwankungen und Pufferkapazitäten der Datenbank nötig. Doch über die Jahre hinweg veränderte sich die Größe von Lobsters nicht grundlegend. Es blieb eine mittelgroße Community-Website, deren Tagesverkehr ein gewöhnlicher Server bewältigt. Trotzdem erzeugte jener 「für alle Fälle」 bereitstehende Datenbankserver monatlich fixe Ausgaben.
Das ist kein Einzelfall. In der Softwarebranche gibt es einen häufigen Fehler namens 「Premature Optimization」 (vorzeitige Optimierung): Für eine Größenordnung bezahlen, die noch gar nicht da ist. Die ersten drei Leute eines Startups bauen schon ein Kubernetes-Cluster, Microservice-Architektur, Master-Slave-Datenbanken auf – nur 「für die spätere Skalierung」. Diese Entscheidungen sind an sich nicht falsch, aber der Preis ist ein dreifacher Anstieg von Wartungskomplexität, Monatsrechnung und Fehlersuche-Schwierigkeit.
Eine Schicht tiefer möchte ich darauf hinweisen: Technisch 「fortschrittlich」 und 「passend」 sind zwei verschiedene Dinge. Eine kostenlose, leichte Datenbank, die Daten in Dateien speichert, sieht auf dem Funktionsblatt tatsächlich weniger glanzvoll aus als eine kommerzielle Datenbank. Aber wenn ihr jene extra Funktionen nicht braucht – etwa Mehrbenutzerrechte, georedundante Replikation, massenhafte gleichzeitige Schreibvorgänge –, dann sind diese Funktionen kein Asset, sondern Ballast.
Selbstverständlich heißt das nicht, dass SQLite für alle Szenarien taugt. thomas0 räumte im Kommentarbereich und in der Diskussion mit anderen Nutzern offen ein: Wenn eine Website massenhafte gleichzeitige Schreibvorgänge benötigt, mehrere Server gleichzeitig auf dieselben Daten zugreifen müssen oder komplexe Benutzerrechteverwaltung braucht, ist SQLite die falsche Wahl. Sein Nebenläufigkeitsmodell ist 「Multi-Read, Single-Write」 – viele können gleichzeitig lesen, aber nur einer darf zu einem Zeitpunkt schreiben. Für eine Community wie Lobsters, bei der 「Nutzer weit mehr lesen als posten」, ist das kein Problem. Für Taobao oder WeChat wäre es eine Katastrophe.
Der Schlüssel liegt in der Handlung, sich ehrlich zu fragen, was man wirklich braucht. Dieses Urteil ist wichtiger als die Wahl der Datenbank-Version.
Zum Schluss
Vom August 2018, als pushcx jenen Diskussions-Thread eröffnete, bis zum 11. Juli 2026, als der zweite Go-Live gelang, spannt die Datenbankmigration von Lobsters fast acht Jahre. Dazwischen lagen ein Fehlschlag, drei Code-Änderungen, ein selbst geschriebenes Testskript, ein selbst geschriebenes Datenbank-Migrationstool sowie unzählige Diskussionen und das 「Wollen wir es noch einmal versuchen」 im Chat-Kanal.
Das Endergebnis ist so einfach, dass es in einem Satz geht: Eine seit über zehn Jahren bestehende Technik-Community tauschte die Datenbank von einem kommerziellen System, das einen eigenen Server brauchte, auf eine kostenlose Datei-Datenbank. Die Serverrechnung halbiert. Der Montagmorgen war sehr ruhig.
Das ist keine Geschichte über 「Disruption」. Es ist eine Geschichte über die Rückkehr zum 「Gut-genug」.
Referenzen
- Lobsters interner Post: Läuft jetzt auf SQLite (von thomas0)
- GitHub-Issue #539: Die vollständige Historie der Migration von MariaDB zu PostgreSQL/SQLite
- Simons Willisons Bericht: Lobsters ist zu SQLite migriert
- pushcx’ Bereitstellungs-Checkliste (Gist): Die vollständigen Schritte beider Go-Lives
- Lobsters Open-Source-Code-Repository (GitHub)