Datenbank-Aufbau für FM ohne IT-Budget: Wie ich mit PostgreSQL und Supabase angefangen habe

Vor zwei Jahren hatte ich ein Problem: 14 Excel-Dateien mit Anlagendaten, Wartungsintervallen, Kostenzuordnungen und Vertragsdetails. Verschiedene Versionen auf verschiedenen Laufwerken. Kollege A hatte die aktuelle Kostentabelle, Kollege B die aktuelle Anlagenliste – nur wusste keiner, wessen Version wirklich aktuell war. Jeder FM-Projektleiter kennt diese Situation.

Meine Lösung war keine große IT-Initiative, kein sechsstelliges Budget und kein externer Berater. Ich habe mir an einem Wochenende PostgreSQL beigebracht und eine Datenbank aufgesetzt. Heute laufen alle meine Projektdaten darüber – und ich würde nie wieder zurück zu Excel gehen.

Warum Excel im FM irgendwann an seine Grenzen stößt

Excel ist ein fantastisches Tool. Für Analysen, für schnelle Berechnungen, für Einzeldateien. Aber als Datenhaltungssystem für operatives FM ist es eine Katastrophe.

Die Probleme, die ich immer wieder sehe: Mehrere Personen arbeiten an verschiedenen Versionen derselben Datei. Formeln werden versehentlich überschrieben. Bei mehr als 10.000 Zeilen wird Excel langsam und unhandlich. Verknüpfungen zwischen verschiedenen Tabellen – Anlagen mit Verträgen mit Kosten – werden über SVERWEIS-Ketten gebaut, die bei der kleinsten Änderung brechen.

Der Punkt, an dem Excel zum Problem wird, ist bei den meisten FM-Teams überraschend früh erreicht: Sobald mehr als drei Personen regelmäßig mit denselben Daten arbeiten, sobald Daten aus verschiedenen Quellen zusammengeführt werden müssen, oder sobald historische Vergleiche über mehr als ein Jahr nötig sind.

Der Einstieg: PostgreSQL und warum ich mich dafür entschieden habe

Ich hatte keine Datenbankererfahrung, als ich angefangen habe. Mein Auswahlprozess war pragmatisch: Welche Datenbank ist kostenlos, gut dokumentiert, und hat eine Community, in der ich Antworten auf Anfängerfragen finde?

PostgreSQL hat alle drei Kriterien erfüllt. Open Source, seit Jahrzehnten bewährt, riesige Community, unzählige Tutorials. Die Einstiegshürde ist höher als bei Excel – ja, ihr müsst SQL-Grundlagen lernen. Aber SQL-Grundlagen heißt: SELECT, INSERT, UPDATE, JOIN. Das sind vier Befehle. Die Syntax passt auf eine Karteikarte.

Für den Einstieg empfehle ich Supabase – eine Plattform, die PostgreSQL als Managed Service anbietet. Kostenloser Einstieg, grafische Oberfläche zum Tabellen-Anlegen, und eine REST-API, die ihr sofort für Dashboards oder Webapps nutzen könnt. Die Datenbank läuft in der Cloud, was den Einstieg drastisch vereinfacht – kein Server-Setup, keine Linux-Kenntnisse nötig.

Wer die Daten lieber auf eigener Infrastruktur hat: PostgreSQL lokal oder auf einem kleinen Server installieren dauert mit Docker circa 30 Minuten.

Meine Datenbankstruktur: Was ich abgebildet habe

Meine FM-Datenbank besteht aus fünf Kerntabellen, die miteinander verknüpft sind.

Die Tabelle „Standorte” enthält alle betreuten Objekte: Name, Adresse, Fläche, Nutzungsart, Vertragsbeginn. Die Tabelle „Anlagen” enthält alle technischen Anlagen pro Standort: Anlagentyp, Hersteller, Baujahr, letzte Wartung, nächste Prüfung. Die Tabelle „Verträge” bildet die Servicestruktur ab: Vertragspartner, Gewerk, Laufzeit, Kosten, Kündigungsfrist. Die Tabelle „Tickets” speichert alle Störmeldungen und Serviceaufträge: Anlage, Standort, Beschreibung, Priorität, Bearbeitungszeit, Status. Die Tabelle „Kosten” erfasst alle FM-Kosten: Rechnungen, Gewerk, Kostenstelle, Zeitraum.

Die Verknüpfung zwischen den Tabellen macht den eigentlichen Mehrwert aus. Eine einfache SQL-Abfrage zeigt mir: Alle Kälteanlagen am Standort München, deren letzte Wartung mehr als sechs Monate zurückliegt, mit den zugehörigen Vertragskosten und der Anzahl der Störmeldungen im letzten Quartal. In Excel wäre das eine Verkettung aus SVERWEIS, ZÄHLENWENN und Pivot-Tabellen. In SQL sind es fünf Zeilen.

Was ich aus dem Prozess gelernt habe

Lektion 1: Startet mit den Daten, die ihr habt. Meine ersten Tabellen waren direkte Importe aus den Excel-Listen – mit allen Fehlern und Lücken. Das ist in Ordnung. Der Umstieg auf eine Datenbank verbessert nicht magisch die Datenqualität, aber er macht Inkonsistenzen sichtbar. Und sichtbar ist der erste Schritt zu sauber.

Lektion 2: Weniger Tabellen, mehr Verknüpfungen. Am Anfang wollte ich für alles eine eigene Tabelle. Zehn Tabellen nach zwei Wochen. Zu komplex. Ich habe zurückgebaut auf fünf Kerntabellen und dafür die Verknüpfungen sauber gemacht. Einfachheit schlägt Vollständigkeit.

Lektion 3: Die Datenerfassung muss einfach sein. Die schönste Datenbank ist nutzlos, wenn niemand Daten eingibt. Ich habe mit Supabase eine simple Eingabemaske gebaut – drei Klicks für eine neue Störmeldung, fünf Felder statt fünfzehn. Die Akzeptanz bei den Kollegen stieg sofort, als die Eingabe schneller ging als das Ausfüllen der alten Excel-Vorlage.

Lektion 4: SQL lernen dauert weniger lang als gedacht. Ich habe einen Online-Kurs gemacht – zehn Stunden über drei Wochenenden. Danach konnte ich die wichtigsten Abfragen selbst schreiben. Für komplexere Sachen frage ich die KI – Claude ist erstaunlich gut darin, SQL-Abfragen auf Basis einer natürlichen Sprachbeschreibung zu generieren.

Was das Ganze kostet

Hier ist die ehrliche Kostenaufstellung meines Setups:

PostgreSQL: kostenlos (Open Source). Supabase: kostenlos für den Einstieg, 25 Dollar pro Monat für die Pro-Version mit mehr Speicher und Backups. Meine Arbeitszeit: circa 40 Stunden für den initialen Aufbau, verteilt über einen Monat. Laufende Pflege: zwei bis drei Stunden pro Woche für Datenbereinigung und kleinere Anpassungen. Dashboard obendrauf mit Apache Superset: ebenfalls kostenlos.

Gesamtkosten im ersten Jahr: 300 Dollar für Supabase Pro plus meine Arbeitszeit. Im Vergleich: Eine CAFM-Lösung für denselben Funktionsumfang hätte ein Vielfaches gekostet – und wäre in drei Monaten nicht einsatzbereit gewesen.

Wann eine Datenbank reicht – und wann ihr doch ein CAFM braucht

Mein Setup ist kein CAFM-Ersatz für einen Konzern mit 50 Standorten und 500 Nutzern. Es ist eine pragmatische Lösung für FM-Teams und Projektleiter, die ihre Daten in den Griff bekommen wollen, ohne auf die IT zu warten.

Wenn ihr mehr als 20 Nutzer habt, die gleichzeitig mit dem System arbeiten, wenn ihr regulatorische Anforderungen an Audit-Trails und Zugriffsprotokollierung habt, oder wenn ihr ein vollintegriertes Flächenmanagement braucht – dann braucht ihr ein echtes CAFM.

Aber für alles dazwischen – für den Projektleiter mit drei Standorten und zehn Kollegen, für die FM-Abteilung, die ihre Vertragsdaten sortieren will, für den Objektleiter, der seine KPIs endlich verlässlich tracken möchte – reicht eine PostgreSQL-Datenbank mit einem Dashboard obendrauf.

Mein konkreter Tipp

Nehmt eure wichtigste Excel-Datei – die, die am meisten Probleme macht. Erstellt einen kostenlosen Supabase-Account. Importiert die Daten in eine Tabelle. Schreibt eure erste SQL-Abfrage. Wenn ihr nach zwei Stunden denkt „Warum habe ich das nicht früher gemacht?” – dann wisst ihr, dass der Weg richtig ist.

Wer von euch arbeitet noch komplett in Excel – und wer hat den Sprung zur Datenbank schon gemacht?