15 Jahre lang war Excel meine Datenbank - Postgres hat das in einem Wochenende beendet.

Über den größten Teil meines Lebens hinweg war meine „Datenbank“ eine Tabellenkalkulation. Alles - von Bestandslisten über Projektverfolgung bis hin zu Budgetaufstellungen - sowie sogar ein selbst entwickeltes CRM-System, das ich mit bedingter Formatierung und der Funktion VLOOKUP zusammengestellt hatte und auf das ich seltsamerweise stolz war - all das befand sich in Excel. Warum? Weil Excel funktionierte, schnell zu öffnen war, einfach zu bearbeiten und weil alle, mit denen ich zusammenarbeitete, bereits wussten, wie man es nutzt.

Dann, an einem schönen Tag, stürzten meine Tabellenkalkulationen unter ihrer eigenen Last ab - und ich brauchte eine richtige Datenbank. Es kostete mich ein Wochenende voller Recherchen und Migrationen, aber Postgres füllte diese Lücke perfekt aus.

Diese Excel-Funktion ersparte Stunden der manuellen Textzusammenfügung.

Das Durchsuchen von Daten ist dank dieser schnellen und einfachen Excel-Formel nun einfacher geworden.

Tabellenblätter wurden schleichend zu meiner Datenbank.

Jahre des Wachstums machten die Grenzen von Excel sichtbar

Niemand plant, irgendwann auf Tabellenkalkulationen zu verzichten. Man wacht nicht eines Tages auf und beschließt, dass es Zeit ist, Excel nicht mehr zu nutzen und auf etwas anderes umzusteigen. Es geschieht schrittweise: Aus einer einzigen Tabelle werden drei Registerkarten, dann zehn - schließlich entsteht eine Hauptdatei, die auf ein halbes Dutzend anderer Dateien verweist. Formeln verweisen plötzlich auf Zellen, die bereits vor Jahren gelöscht wurden. Dann macht jemand einen Fehler beim Einstellen eines Filters - plötzlich verschwinden die Hälfte der Zeilen. Man bemerkt das erst, wenn es darum geht, aus diesem Datenchaos, das man als „Datenbank“ bezeichnet, etwas Nützliches herauszuholen.

Das eigentliche Problem sind nicht die Fehler selbst; es ist vielmehr, dass die Schutzmechanismen in Excel alle optional sind. Man könnte zwar Fehlerprüfungen durch Excels Datenvalidierung ersetzen, um Fehler vor ihrem Auftreten zu verhindern - und Power Pivot kann sogar Beziehungen zwischen Tabellen modellieren. Doch fast niemand richtet solche Mechanismen ein, und nichts hindert einen daran, sie später zu umgehen. Es gibt keine zwingend einzuhaltende Beziehung zwischen Tabellen - so wie es ein Fremdschlüssel in Datenbanken gewährleistet. Jeder Schutzmechanismus erfordert manuelles Handeln - und Gewohnheiten brechen unter Zeitdruck häufiger zusammen, als man gerne hätte.

Postgres löste Probleme, die Excel niemals lösen konnte

Entwickelt für strukturierte, zuverlässige Daten

Mein Wendepunkt kam, als mir klar wurde, dass ich drei Tabellenkreuzverweise erstellen musste, um eine Frage zu beantworten, für die eigentlich nur 30 Sekunden nötig gewesen wären. Stattdessen kostete mich das eine ganze Nachmittag lang andauernde Arbeit mit VLOOKUP-Funktionen und Kopieren/Einfügen - und ich war mir immer noch nicht sicher, ob die Antwort korrekt war. Diese Frustration veranlasste mich schließlich dazu, nach einer Datenbanklösung zu suchen - und Postgres war die perfekte Wahl. Es lässt sich leicht einrichten, läuft als containerisierter Dienst und lässt sich problemlos in lokale LLMs zur KI-Analyse integrieren.

Angesichts meiner üblichen Vorgehensweise, Dienste in Docker zu betreiben - diese sechs Docker-Container haben meinen Heimserver bereits lange vor diesem Projekt lohnenswert gemacht - war es kein großer Aufwand, Postgres zum Laufen zu bringen. Man braucht nur die Grundvoraussetzungen; eine Docker Compose-Datei samt einem benannten Volume für die dauerhafte Speicherung reichte aus, um Postgres in weniger als 10 Minuten zum Laufen zu bringen. Zudem hatte ich bereits Erfahrung mit Postgres - als ich Claudes Speicherprobleme behebte, indem ich ihm eine Postgres-Datenbank zur Verfügung stellte.

Ein Wochenende hat gereicht.

Der Migrationsprozess verlief einfacher als erwartet.

Der Migrationsprozess erforderte etwas Planung, war aber im Grunde einfach durchzuführen. Ich begann mit meiner chaotischsten Tabelle - einem Kunden- und Bestellverfolgungssystem, das mithilfe von Formeln zusammengehalten wurde - und skizzierte die eigentlichen Tabellen: Kunden, Bestellungen, Zahlungen. Allein diese Übung, bei der ich in normalisierten Tabellen statt in flachen Zeilen dachte, zeigte mir, wie viele doppelte und inkonsistente Daten ich jahrelang mit mir herumgetragen hatte. Anschließend schrieb ich ein kleines Python-Skript, das mit Pandas die alte Datei einliest, bereinigt und anschließend mithilfe von Psycopg - dem beliebtesten Python-Adapter für Postgres - alle Daten in Postgres einfügt.

Damit wurde das Schema mit Fremdschlüsseln und Einschränkungen eingerichtet. Am nächsten Tag beobachtete ich, wie diese Einschränkungen die Arbeit erledigten, die ich früher manuell machen musste. Ein Unternehmen war in der Tabelle zweimal unter derselben E-Mail-Adresse aufgeführt; Monate später wurde es erneut eingetragen - diesmal mit einem nachgestellten Leerzeichen im Namen, wodurch es wie ein neuer Eintrag aussah. Die Eindeutigkeitsprüfung bezüglich der E-Mail-Adresse verhinderte jedoch den doppelten Eintrag. Bei einer Bestellung fehlte ganz das Datum; die Einschränkung, dass dieses Feld nicht leer sein darf, verhinderte, dass diese Bestellung meine Daten „verunreinigte“ (ich musste den ursprünglichen Eintrag trotzdem finden und korrigieren).

Ein anderer verwies auf eine Kunden-E-Mail, die überhaupt nicht auf der Liste stand - genau die Art von fehlerhaftem Eintrag, für den VLOOKUP einfach einen leeren Wert zurückgibt. Postgres lehnte diesen Eintrag jedoch ab, da er gegen die Regeln bezüglich Fremdschlüssel verstieß. Bei einer Zahlung war in der Spalte für den Betrag „vollständig bezahlt“ eingetragen statt einer Zahl; Postgres weigerte sich zunächst, diesen Wert als Währungswert zu speichern, bis ich ihn korrigierte.

Allerdings wurde nicht jede unordentliche Spalte zu einer „dramatischen“ Situation. In meiner Spalte mit Rechnungsinformationen waren die Werte „ja“, „nein“, „true“ und „N“ verstreut - Postgres’ Boolean-Typ verarbeitete fast alle dieser Werte problemlos. Einschränkungen verhindern zwar ungültige Daten, aber keine fehlerhafte Formatierung.

Alles wurde einfacher zu verwalten.

Sauberere Daten, schnellere Abfragen, weniger Fehler

Der Unterschied liegt nicht nur in der Geschwindigkeit - obwohl das ein großer Vorteil ist. Die Aufgabe, Rechnungen für Kunden zu erstellen, die früher einen ganzen Nachmittag in Excel in Anspruch nahm, ist nun eine fünfzeilige SQL-Abfrage; mein Flash-Dashboard zeigt das Ergebnis bereits beim Laden der Seite an. Ich muss mich nicht mehr fragen, ob eine Formel in die falsche Zelle geraten ist oder ob jemand einen Wert überschrieben hat. Die Datenbank stellt Regeln durchsetzbar, die ich früher nur durch Gedächtnis und Aufmerksamkeit einhalten konnte. Falls sie das nicht schafft, gibt es einen deutlichen Fehlerhinweis - und ich muss das Problem beheben, bevor es sich ausweitet.

Ein weiterer großer Vorteil ist, dass ich mittlerweile buchstäblich mit meinen Daten „reden“ kann - dank einiger lokaler LLMs sowie Claude, die alle Zugriff auf dieselbe Datenbank haben. In den meisten Fällen muss ich dabei nicht einmal SQL schreiben; es reicht aus, meine KI-Agenten zu bitten, mir die gewünschten Daten zu finden. Außerdem werden Backups nun regelmäßig erstellt - anstatt dass ich hoffen muss, daran gedacht zu haben, vor dauerhaften Änderungen eine gesicherte Kopie anzufertigen.

Excel hat immer noch seinen Platz

Gut geeignet für die Analyse, nicht für die Langzeitaufbewahrung

Excel ist nicht nutzlos - ich verwende es immer noch, um Daten mit Leuten zu teilen, die keine SQL-Abfragen ausführen werden. Doch als Datenspeichersystem wurde es nie für die Aufgabe entwickelt, die ich von ihm erwartete.

Die Lösung für lokale LLMs war niemals ein größeres Modell.

Mein lokales LLM hatte ständig Probleme mit dem Kontext, bis ich dieses 500 MB große Modell hinzugefügt habe.

Postgres hat bei mir nicht einfach nur ein Werkzeug ersetzt. Es hat ein instabiles Denkmuster ersetzt, an dem ich schon sehr lange herumgebastelt hatte. Das Einzige, was ich bedauere, ist, dass ich nicht früher umgezogen bin.