Diese Fallstudie dokumentiert, warum wir ein backend-lastiges Produktivsystem von gemanagten Infrastruktur-SaaS-Anbietern wie Supabase und Railway weg und auf eine Infrastruktur migriert haben, die wir selbst kontrollieren.
Abstract
Diese Fallstudie dokumentiert, warum wir ein backend-lastiges Produktivsystem von gemanagten Infrastruktur-SaaS-Anbietern wie Supabase und Railway weg und auf eine Infrastruktur migriert haben, die wir selbst kontrollieren.
Das war keine normale Migrationsgeschichte. Es ging nicht einfach darum, ein paar Euro beim Hosting zu sparen. Es war das Ergebnis einer tieferen Erkenntnis: Viele moderne Infrastruktur-SaaS-Unternehmen sind nicht wirklich auf die Kunden ausgerichtet, die auf ihnen aufbauen. Sie sind auf messbare Abhängigkeit ausgerichtet.
Sie machen den Einstieg einfach. Sie lassen das erste Projekt günstig wirken. Sie schaffen eine polierte Developer Experience. Sie ermutigen Teams dazu, schnell und tief innerhalb ihres Ökosystems zu bauen.
Und sobald die Workload real wird, wird plötzlich alles zu einer abrechenbaren Grenze.
RAM wird zu einer Abrechnungsgrenze.
CPU wird zu einer Abrechnungsgrenze.
I/O wird zu einer Abrechnungsgrenze.
Egress wird zu einer Abrechnungsgrenze.
Storage wird zu einer Abrechnungsgrenze.
Throughput wird zu einer Abrechnungsgrenze.
Function Calls werden zu einer Abrechnungsgrenze.
Logs werden zu einer Abrechnungsgrenze.
Support wird zu einer Abrechnungsgrenze.
Zuverlässigkeit wird zu einer Abrechnungsgrenze.
An diesem Punkt kauft der Kunde keine Bequemlichkeit mehr. Der Kunde zahlt Miete auf Abhängigkeit.
Unsere eigene Erfahrung mit Supabase hat das schmerzhaft deutlich gemacht. Wir hatten ihrem Ökosystem erheblichen geschäftlichen Wert gebracht. Wir hatten viele Kunden an Supabase herangeführt, an hunderten Supabase-Projekten gearbeitet und echte Produktivsysteme auf ihrer Plattform gebaut. Doch als eine produktive Datenbank wiederholt in Crash-Zyklen geriet und wir um einen moderaten zusätzlichen Speicherpuffer baten, lautete die Antwort im Kern: kein kostenloses Ressourcen-Upgrade; optimiert eure Workload oder wählt einen Plan mit passenderen Ressourcen. Der Supabase-Support bestätigte Out-of-Memory-Ereignisse, I/O-Spitzen, RAM-Instabilität, Query-Druck und Datenbank-Crash-Zustände, in denen selbst einfache Queries nicht mehr verarbeitet werden konnten.
Diese Antwort klärte die Beziehung.
Wir wurden nicht als strategischer Partner behandelt.
Wir wurden als gemessene Workload behandelt.
Deshalb sind wir gegangen.
Das zentrale Argument
Das zentrale Argument dieser Fallstudie ist einfach:
Infrastruktur-SaaS ist nützlich, bis es zum Vermieter wird.
Am Anfang fühlt sich SaaS-Infrastruktur wie Hebelwirkung an. Man deployed schneller. Man vermeidet Server-Setup. Man muss Postgres, Backups, Reverse Proxies, Monitoring, Background Worker oder Storage-Infrastruktur nicht manuell konfigurieren.
Das ist in der Prototypenphase ein echter Wert.
Aber sobald das System ernst wird, verändert sich die Beziehung.
Der Anbieter besitzt die Control Plane.
Der Anbieter besitzt die Ressourcengrenze.
Der Anbieter besitzt das Preismodell.
Der Anbieter besitzt das Support-Eskalationspfad.
Der Anbieter besitzt die finale Antwort, wenn man nach mehr Kapazität fragt.
Der Kunde besitzt den Ausfall.
Der Kunde besitzt den geschäftlichen Schaden.
Der Kunde besitzt den Druck des eigenen Kunden.
Der Kunde besitzt das Notfall-Debugging.
Der Kunde besitzt die Rechnung.
Das ist keine Infrastrukturpartnerschaft. Das ist Monetarisierung von Abhängigkeit.
Projektkontext
Das System, das wir migriert haben, war keine Spielzeug-App.
Es war ein backend-lastiges analytisches System mit geplanten Jobs, Strategieauswertung, Lifecycle Scoring, Paper-Trading-Analyse, Kandidatengenerierung, Pattern Discovery, Dashboard Health Checks, Risikozusammenfassungen und Klassifizierung technischer Fehler.
Das System musste zwischen echten Strategiefehlern und technischen Fehlern unterscheiden. Technische Exits mussten fürs Debugging gespeichert, aber aus der Strategie-Performance-Evidenz ausgeschlossen werden — über Lifecycle Scoring, Reports, Risk Summaries, Strategy Health und Promotion Evidence hinweg. Das System hatte außerdem eine Validierungsschleife mit hunderten bestandenen Tests, einschließlich einer vollständigen Suite von 754 bestandenen Tests vor einem der größeren Pushes.
Das ist wichtig, weil die Workload kein zufälliger Missbrauch war.
Das System verrichtete legitime Backend-Arbeit.
Es las.
Es schrieb.
Es analysierte.
Es plante.
Es validierte.
Es loggte.
Es bewertete.
Es verarbeitete operativen Zustand.
Genau das tut produktive Backend-Software.
Wenn eine gemanagte Datenbank das nicht aushält, ohne wiederholt in Crash-Zustände zu geraten, dann ist das Problem nicht einfach: „Eure App sollte kleiner sein.“ Das Problem ist, dass die Plattformgrenze zu fragil für die Workload ist, zu der sie Kunden selbst ermutigt hat.
Der Supabase-Vorfall
Der Wendepunkt war ein Supabase-Instabilitätsvorfall.
Der initiale Fehler war gravierend. Cloudflare symbols/Origin versuchte, eine Verbindung zum Supabase-Datenbank-Origin aufzubauen, aber der Origin antwortete nicht innerhalb des Timeout-Fensters. Der Fehler betraf nicht nur normale Reads wie GET /rest/v1/research_jobs, sondern auch Log-Writes wie POST /rest/v1/system_logs und sogar interne administrative Operationen.
Der Supabase-Support beschrieb das Problem später als Out-of-Memory-Crash. Die eigene Erklärung verwies auf instabilen RAM, starke Spitzen, Reporting-Lücken, hohe I/O-Wait-Zeiten, übermäßige I/O-Aktivität und zeitüberschreitende Queries gegen die Tabelle ai_analyses. Außerdem wurde angedeutet, dass breite Rows, JSONB, lange Textfelder und das Selektieren aller Spalten zu RAM-Spitzen beitragen könnten.
Dann wurde die Situation noch klarer: Auch leichtgewichtige Queries liefen in Timeouts. Wir meldeten, dass selbst eine sehr kleine Query gegen scheduler_leases timeoutete, was bedeutete, dass die Datenbank nicht einmal einfache SQL-Anfragen zuverlässig annahm. Der Supabase-Support bestätigt, dass das System in einem gecrashten Zustand keine Query verarbeiten konnte — auch keine sehr einfachen, weder über SQL noch über API-Requests.
Das ist der entscheidende Punkt.
Es war nicht nur ein langsames Dashboard.
It was not only a single endpoint.
Die Datenbank wurde als System nicht verfügbar.
Die eigentliche Anfrage war bescheiden
Das Frustrierende daran ist: Die Anfrage war nicht extravagant.
Wir baten Supabase nicht darum, ihre Plattform neu zu entwerfen.
Wir baten nicht um eine individuelle Enterprise-Architektur.
Wir baten nicht um ein dediziertes Engineering-Team.
Wir baten im Kern um einen moderaten zusätzlichen Speicherpuffer — etwa 2 GB RAM — damit eine Produktionsinstanz nicht weiter in Crash-Zyklen gerät.
Das hätte eine einfache kommerzielle Entscheidung sein müssen.
Ein Kunde, der über hundert Kunden oder Kundenbeziehungen in das Ökosystem gebracht hat und an mehr als 400 Supabase-Projekten gearbeitet hat, sollte nicht wie irgendein Hobby-Account behandelt werden, wenn ein Produktivsystem wiederholt ausfällt.
Die richtige geschäftliche Reaktion wäre offensichtlich gewesen:
Gebt dem Kunden temporär Headroom.
Stabilisiert die Instanz.
Erhaltet die Beziehung.
Schützt das Vertrauen in das Ökosystem.
Arbeitet danach gemeinsam an Optimierungen.
Stattdessen kam die Standard-SaaS-Wand: Workload optimieren, Diagnostik aktivieren, Batching nutzen, Index Advisor laufen lassen oder einen Plan wählen, dessen Ressourcen besser zur Workload passen. Supabase lehnte ein kostenloses Ressourcen-Upgrade ausdrücklich ab.
Das war der Moment, in dem sich die Beziehung veränderte.
Es hieß nicht mehr: „Wir helfen euch beim Skalieren.“
Es hieß: „Ihr habt die Ressourcengrenze überschritten; jetzt zahlt.“
Warum das nicht akzeptabel war
Es gibt einen Unterschied zwischen Optimierungshinweisen und Infrastrukturverantwortung.
Ja, Queries sollten optimiert werden.
Ja, Indexes sind wichtig.
Ja, alle Spalten aus breiten JSONB-lastigen Tabellen zu selektieren, kann ineffizient sein.
Ja, Batching kann Speicherbelastung reduzieren.
Kein ernsthafter Engineer bestreitet das.
Aber das ist nicht die ganze Geschichte.
Die ganze Geschichte ist, dass eine gemanagte Produktivdatenbank wiederholt in Crash-Zustände geriet und selbst einfache Queries nicht mehr verarbeiten konnte. Der Supabase-Support beschrieb OOM-Ereignisse, I/O-Spitzen, RAM-Instabilität und System-Crash-Verhalten.
Wenn eine Datenbank an den Punkt kommt, an dem selbst einfache SQL-Anfragen nicht mehr angenommen werden können, führt der Kunde keine normale Optimierungsdiskussion mehr. Der Kunde steht vor einer Plattform-Zuverlässigkeitsgrenze.
Und wenn die Antwort des Anbieters im Kern lautet: „Zahlt für mehr Ressourcen“, dann wird das kommerzielle Modell offengelegt.
Der Anbieter besitzt die Kapazität.
Der Kunde besitzt die Konsequenzen.
Genau deshalb sollten ernsthafte Systeme nicht dauerhaft von diesem Modell abhängig bleiben.
Die brutale Wahrheit über Infrastruktur-SaaS
Ein großer Teil von Infrastruktur-SaaS ist keine Innovation.
Es ist Verpackung.
Es ist Postgres mit Dashboard.
Es sind Container mit Dashboard.
Es sind Cron Jobs mit Dashboard.
Es ist Object Storage mit Dashboard.
Es sind Logs mit Dashboard.
Es sind Deployment Scripts mit Dashboard.
Es ist eine polierte Oberfläche um Infrastruktur-Primitives herum, die Teams früher selbst betrieben haben.
Diese Verpackung ist am Anfang nützlich. Aber sie wird gefährlich, wenn Teams Verpackung mit Besitz verwechseln.
Supabase hat Postgres nicht erfunden.
Railway hat Container nicht erfunden.
Vercel hat HTTP nicht erfunden.
Render hat Deployment nicht erfunden.
Firebase hat Datenbanken nicht erfunden.
Diese Plattformen verpacken nützliche Primitives und verkaufen Bequemlichkeit. Das ist in Ordnung.
Das Problem beginnt, wenn sie zu permanenten Vermietern über kritische Infrastruktur werden.
Denn in dem Moment, in dem das System wächst, fragmentiert sich die Rechnung.
Mehr RAM? Zahl.
Mehr CPU? Zahl.
Mehr I/O? Zahl.
Mehr Egress? Zahl.
Mehr Storage? Zahl.
Mehr Functions? Zahl.
Mehr Logs? Zahl.
Mehr Support? Zahl.
Mehr Zuverlässigkeit? Zahl.
Mehr Headroom? Zahl.
Irgendwann baut der Kunde keine Software mehr. Der Kunde verwaltet eine kommerzielle Beziehung mit einem Zähler.
SaaS-Anbieter monetarisieren Migrationsangst
Der stärkste Lock-in ist heute nicht mehr technisch.
Er ist psychologisch.
Die meisten Teams bleiben, weil sie Angst haben zu gehen.
Sie denken, die Migration sei zu schwer.
Sie denken, Supabase Auth zu ersetzen sei zu schwer.
Sie denken, die Datenbank umzuziehen sei zu schwer.
Sie denken, Storage-Pfade umzuschreiben sei zu schwer.
Sie denken, Edge Functions zu ersetzen sei zu schwer.
Sie denken, den Stack zu dockerisieren sei zu schwer.
Sie denken, Backups einzurichten sei zu schwer.
Sie denken, Postgres selbst zu betreiben sei zu schwer.
Genau von dieser Angst profitieren SaaS-Anbieter.
Sie müssen dich nicht einsperren.
Sie müssen dich nur glauben lassen, dass Gehen schmerzhafter ist als Zahlen.
Aber 2026 ist dieser Glaube veraltet.
KI-gestützte Entwicklung hat die Migrationsgleichung verändert.
Adapter lassen sich leichter schreiben.
Migrationsskripte lassen sich leichter generieren.
Schema-Exports lassen sich leichter validieren.
Kompatibilitätsschichten lassen sich leichter bauen.
Docker-Compose-Dateien lassen sich leichter erstellen.
Reverse-Proxy-Konfigurationen lassen sich leichter produzieren.
Health Checks lassen sich leichter implementieren.
Datenexporter lassen sich leichter testen.
Ersatzservices lassen sich leichter scaffolden.
Die Ausrede „Wir stecken fest, weil Migration zu schwer ist“ wird jedes Jahr schwächer.
Für viele Teams ist Vendor Lock-in keine technische Unvermeidbarkeit mehr.
Es ist tolerierte Abhängigkeit.
Warum wir dieses Abhängigkeitsmodell ablehnen
Unsere Schlussfolgerung war einfach:
Wir werden nicht zulassen, dass ein SaaS-Anbieter normales Backend-Wachstum in eine Bestrafung verwandelt.
Wir werden nicht für immer Premium-Margen für Commodity-Infrastruktur zahlen.
Wir werden nicht zulassen, dass ein Produktionsdatenbank-Crash-Zyklus zu einem Upsell-Event wird.
Wir werden eine 2-GB-RAM-Anfrage nicht so behandeln, als wäre sie eine unvernünftige Enterprise-Forderung.
Wir werden keine Kunden in ein Ökosystem bringen, das ernsthafte Kunden nicht schützt, sobald die Plattformgrenze zum Bottleneck wird.
Wir werden keine ernsthafte Infrastruktur auf einem Modell bauen, bei dem die Antwort auf Instabilität immer lautet: „Optimiert härter oder zahlt mehr.“
Das ist nicht nachhaltig.
Das ist keine Partnerschaft.
Das ist Infrastruktur-Rent-Seeking.
Was wir stattdessen gebaut haben
Die Alternative war, uns in Richtung Infrastruktur zu bewegen, die wir selbst kontrollieren.
Das bedeutet:
Eigene Serverinfrastruktur.
Docker-basiertes Deployment.
Explizite Runtime-Konfiguration.
Kontrolle über den Reverse Proxy.
Sauberes Environment Management.
Direkter Log-Zugriff.
Direkte operative Kontrolle.
Kontrollierte Scheduled Jobs.
Bessere Fehlerklassifizierung.
Vorhersehbarere Kostenstruktur.
Weniger Abhängigkeit von vendor-spezifischen Dashboards.
Das war kein „Rückschritt“.
Das war die Rückeroberung der Infrastrukturebene.
Modernes Self-Hosting ist kein primitives, manuelles, fragiles Setup. Es kann containerisiert, dokumentiert, überwacht, gesichert, getestet und automatisiert werden.
Der Unterschied ist Ownership.
Wenn wir mehr RAM brauchen, können wir ihn provisionieren.
Wenn wir Logs prüfen müssen, können wir sie prüfen.
Wenn wir Scheduling ändern müssen, können wir es ändern.
Wenn wir die Datenbank tunen müssen, verhandeln wir nicht mit einer Pricing Page.
Wenn wir erneut migrieren müssen, sind wir nicht in einem proprietären Workflow gefangen.
Die wirtschaftliche Lektion
Die wirtschaftliche Lektion ist brutal einfach:
Wenn ein Anbieter dir für jede normale Sache, die deine Software tut, separat Geld berechnet, ist der Anbieter nicht dein Infrastrukturpartner.
Er ist dein Vermieter.
Und Vermieter optimieren auf Miete.
Sie optimieren nicht auf deine Unabhängigkeit.
Sie optimieren nicht auf deine Margen.
Sie optimieren nicht auf deine Migrationsfreiheit.
Sie optimieren darauf, dich im Gebäude zu halten und mit deinem Wachstum mehr abzurechnen.
Deshalb muss Infrastruktur-SaaS mit Misstrauen behandelt werden, sobald ein System ernst wird.
Nutze es früh.
Nutze es für Prototypen.
Nutze es für temporäre Beschleunigung.
Nutze es dort, wo es dir einen eften operativen Vorteil gibt.
Aber verwechsle Bequemlichkeit nicht mit Eigentum.
Und verwechsle ein schönes Dashboard nicht mit Infrastrukturreife.
Was wir gelernt haben
Die erste Lektion ist, dass SaaS-Loyalität meistens einseitig ist.
Du kannst Kunden bringen.
Du kannst hunderte Projekte bauen.
Du kannst die Plattform empfehlen.
Du kannst Umsatz für das Ökosystem schaffen.
Aber wenn du an die Ressourcengrenze stößt, kann die Antwort trotzdem lauten: kein kostenloses Upgrade.
Das ist klärend.
Die zweite Lektion ist, dass gemanagte Infrastruktur Kontrolle vom Builder wegverlagert.
Der Anbieter kontrolliert die Kapazität.
Der Anbieter kontrolliert die Quote.
Der Anbieter kontrolliert den Support-Pfad.
Der Anbieter kontrolliert das Pricing.
Der Anbieter kontrolliert die Upgrade-Leiter.
Der Kunde kontrolliert die Konsequenzen.
Die dritte Lektion ist, dass KI-gestützte Migration das Spiel verändert hat.
Wegzugehen ist nicht mehr so schwer, wie Anbieter ihre Kunden glauben lassen wollen. Es braucht weiterhin Disziplin, aber es ist kein Grund mehr, gefangen zu bleiben.
Die fourth Lektion ist, dass viele SaaS-Produkte als temporäres Gerüst behandelt werden sollten, nicht als permanente Architektur.
Ein Gerüst hilft beim Bauen.
Es ist nicht das Gebäude.
Fazit
Wir sind gegangen, weil die Beziehung keinen Sinn mehr ergab.
Das System war ernst.
Die Workload war real.
Die Datenbank geriet in Crash-Zustände.
Der Supabase-Support bestätigte OOM-Verhalten, I/O-Spitzen, instabilen RAM und Situationen, in denen selbst einfache Queries während Crash-Zuständen nicht verarbeitet werden konnten.
Wir baten um moderaten zusätzlichen Headroom.
Die Antwort war: kein kostenloses Upgrade.
Das war das Geschäftsmodell, das sprach.
Nicht der Marketingtext.
Nicht die developer-freundliche Landingpage.
Nicht das startup-freundliche Messaging.
Das echte Modell.
Sobald die Workload wächst, zahl mehr.
Sobald die Ressourcengrenze weh tut, zahl mehr.
Sobald die Datenbank mehr Headroom braucht, zahl mehr.
Sobald dein Produktivsystem Stabilität braucht, zahl mehr.
Deshalb sind wir migriert.
Nicht weil Server gerade modern sind.
Nicht weil Self-Hosting romantisch ist.
Nicht weil SaaS immer schlecht ist.
Wir sind gegangen, weil ernsthafte Systeme keine Mieter in Infrastruktur bleiben sollten, die sie besitzen können.
Im Jahr 2026 gibt es mit Docker, Postgres, Open-Source-Tooling, KI-generierten Migrationshelfern, Kompatibilitätsschichten und moderner Deployment-Automatisierung kaum noch eine Ausrede, in einem überteuerten Infrastruktur-SaaS-Produkt gefangen zu bleiben.
Nutze SaaS für Geschwindigkeit.
Nutze SaaS für Prototypen.
Nutze SaaS dort, wo der Anbieter dir eine Fähigkeit gibt, die du realistisch nicht selbst reproduzieren kannst.
Aber wenn der Anbieter dir lediglich Commodity-Infrastruktur zurückvermietet, jede normale Skalierungsdimension metert und sich weigert, einen ernsthaften Kunden wegen eines kleinen Ressourcen-Headrooms zu schützen, dann geh.
Baue deinen eigenen Stack.
Besitze deine Runtime.
Besitze deine Datenbank.
Besitze deine Margen.
Besitze deine Zukunft.
Passende nächste Schritte
Vertiefen Sie das Thema mit den wichtigsten Service- und Projektseiten.
Blockchain Entwicklung Köln
Wie wir dezentrale Anwendungen (dApps), Smart Contracts und Web3-Systeme in Köln konzipieren und entwickeln.
So wählen Sie das richtige Backend für Ihr Mobile App MVP
Ein strategischer Leitfaden zur Auswahl der passenden Backend-Architektur für Startups und MVPs.
Supabase Security RLS-Fehler vermeiden
Erfahren Sie, wie Sie typische Fehler bei Row Level Security (RLS) in Supabase-Backends vermeiden.
