Analyse- und Prognoseplattform auf TimescaleDB

Dies ist unser eigenes Produkt — wir haben es selbst gebaut und betreiben es selbst. Es ist weder ein Kundenauftrag noch eine Demo für Präsentationen: Die Plattform läuft produktiv auf unserem VPS und hat reale Nutzerinnen und Nutzer. Im Datenbereich ist das ein stärkeres Argument als eine bloße Erklärung.

Was es ist

Eine Plattform, die Daten kontinuierlich sammelt, sie als Zeitreihen speichert und daraus Kennzahlen, Prognosen und Berichte macht.

• Als dauerhafte Dienste betriebene Kollektoren rufen Daten ab, normalisieren sie und speichern sie in der Datenbank; Monitoring legt Unterbrechungen offen.
• Eine Zeitreihendatenbank (TimescaleDB auf PostgreSQL) als einzige Quelle der Wahrheit für die gesamte Messhistorie.
• Analyse- und Prognoseschicht — Statistik und Modelle werden auf denselben Daten berechnet, ohne manuellen Export in Tabellen.
• Oberfläche mit Dashboards, Roadmap und Audit-Tab — der Projektstatus ist sichtbar, nicht nur erzählt.
• Wiederkehrende Berichte, einschließlich Investorenberichte, sowie Meldungen zu Einführungen auf Discord.
• Nutzer-Community auf Discord — die kürzeste Feedback-Schleife, die wir kennen: Eine Meldung erreicht uns sofort statt erst in einem Quartalsreview.

Welches Problem es löst

Drei Situationen aus der Praxis, die diese Plattform schließt:

• Daten liegen an mehreren Orten, ein Gesamtbild fehlt. Ein Bericht wird manuell zusammengesetzt, entsteht deshalb selten und immer erst im Nachhinein.
• Eine Messung ohne Historie beantwortet nicht die Frage „Ist es besser als vor einem Monat?“ Zeitreihen können das, weil sie jeden Zustand speichern, nicht nur den letzten.
• Ein Pilot auf dem Laptop beantwortet nicht „Was passiert mitten in der Nacht?“ Ein Kollektor als Serverdienst schon — und er meldet selbst, wenn er nicht mehr sammelt.

Wie wir es gebaut haben

Die Kollektoren sind Python-Dienste, die kontinuierlich auf einem VPS laufen und durch Monitoring überwacht werden. Die entscheidende Designentscheidung: Ein Ausfall eines Kollektors muss sichtbar sein, nicht still — eine Datenlücke ist schlimmer als fehlende Daten, weil sie wie ein Ergebnis aussieht.

Die Daten gehen in TimescaleDB, also PostgreSQL mit zeitbasierter Partitionierung und Aggregationen für Zeitreihen. Dasselbe ließe sich in reinem Postgres bauen, aber nicht kostenlos: Hier erhalten wir es als Eigenschaft der Datenbank statt als wartbaren Code.

Logik und API liegen in Python (FastAPI), die Ansichtsschicht in Next.js und React. Datenbankmigrationen liegen im Repository und werden vor dem Übertragen auf den Server geprüft. Ein tägliches Audit prüft drei Dinge: ob die Migrationen übereinstimmen, was die Logs sagen und ob die Kollektoren tatsächlich Daten sammeln — Abweichungen werden als Reparaturplan festgehalten.

Die Einführung umfasst VPS, Systemdienste, Monitoring und Backups. Bewusst ohne „magisches Cloud-Deployment“ — die Umgebung lässt sich beschreiben, reproduzieren und zusammen mit dem Code übergeben.

Was es belegt

Dass wir ein Datensystem produktiv liefern und danach daranbleiben können — mit Kollektoren, Monitoring, Migrationen und Reporting statt nur mit einem Dashboard-Screenshot. Das ist ein direkter Beleg für die Leistung Daten und Analyse; die Kollektoren sind zugleich ein produktives Beispiel für Prozessautomatisierung.

Wir zeigen hier keine fremden Daten — es ist unsere eigene Plattform, deshalb können wir offen über Architektur und Mechanik sprechen. So arbeiten wir: Prozess. Womit wir bauen: Stack.