Warum KI-gebaute Apps nicht skalieren – und wie man es behebt

Ein KI-Assistent baut, was man ihm sagt – Funktion für Funktion, Chat für Chat. Das ist genau seine Stärke, und genau daraus entsteht das typische Architektur-Muster von Vibe-Coding-Projekten: Alles wächst dort, wo gerade Platz ist. Nach ein paar Wochen funktioniert die App, aber niemand – auch die KI nicht – kann sie noch gefahrlos ändern.

Das Muster: eine Datei, die alles macht

Fast jedes Projekt, das wir sehen, hat eine zentrale Datei, in der sich alles sammelt: Routing, Login, Geschäftslogik, Datenbankzugriff, oft sogar HTML. Beim Frontend ist es dasselbe – eine einzige riesige Seite mit hunderten Kilobyte eingebettetem JavaScript.

Das passiert nicht aus Nachlässigkeit, sondern aus der Arbeitsweise: «Füge eine Export-Funktion hinzu» landet dort, wo der Code schon steht. Niemand sagt der KI, dass Export eigentlich ein eigenes Modul sein sollte.

Die Folgen zeigen sich erst später:

• Jede Änderung trifft alles. Eine neue Funktion verändert Code, der mit ihr nichts zu tun hat. Fehler tauchen an unerwarteten Stellen auf.
• Testen ist kaum möglich. Wenn Logik, Datenbank und HTTP in einer Funktion stecken, lässt sich nichts isoliert prüfen. In den meisten Projekten gibt es deshalb schlicht keine Tests.
• Zwei Leute können nicht parallel arbeiten. Alle ändern dieselbe Datei.
• Die KI wird selbst schlechter. Je grösser eine Datei, desto mehr übersieht der Assistent – und desto öfter «repariert» er Dinge, die nicht kaputt waren.

Das Problem ist nicht der Monolith an sich. Das Problem ist die fehlende Trennung der Verantwortlichkeiten innerhalb des Monolithen.

Das ist wichtig, weil die naheliegende Reaktion falsch ist. Eine App aus einer Datei braucht keine Microservices. Sie braucht einen modularen Monolithen: eine Anwendung, ein Deployment – aber intern klar getrennte Schichten für API, Geschäftslogik und Datenzugriff.

SQLite: gute Datenbank, falscher Ort

SQLite ist eine hervorragende Datenbank. Für einen Prototyp, ein internes Tool oder eine überwiegend lesende Anwendung auf einem Server ist sie oft sogar die beste Wahl: keine Installation, keine Verbindung, schnell. Mit aktiviertem WAL-Modus laufen Lesen und Schreiben auch gut nebeneinander.

Zum Problem wird SQLite, sobald die App wachsen soll:

• Die Datenbank ist eine Datei auf einem Server. Ein zweiter Server für mehr Kapazität oder Ausfallsicherheit kann sie nicht sinnvoll mitbenutzen. Horizontal skalieren geht nicht.
• Es schreibt immer nur einer. Viele gleichzeitige Schreibvorgänge – etwa wenn Nutzer Daten erfassen und ein Import läuft – stauen sich.
• Bei Containern und Serverless-Plattformen droht Datenverlust. Liegt die Datei im Dateisystem des Containers statt auf einem dauerhaften Volume, ist sie beim nächsten Deployment weg. Das sehen wir erstaunlich oft.
• Schema-Änderungen passieren «nebenbei». Meist ändert der Anwendungscode die Tabellen beim Start. Welche Datenbank auf welchem Stand ist, weiss irgendwann niemand mehr.

Die ehrliche Antwort auf «Muss ich weg von SQLite?» lautet deshalb: nicht sofort, aber bevor Sie mehr als einen Server, viele gleichzeitige Schreiber oder zahlende Firmenkunden mit Verfügbarkeitsansprüchen haben. Die Zielplattform ist dann in der Regel PostgreSQL – mit versionierten Migrationen, damit jede Schemaänderung nachvollziehbar und wiederholbar ist.

Der unsichtbare Blocker: Zustand im Arbeitsspeicher

Ein Muster, das selten auffällt, bis es zu spät ist: Angemeldete Sitzungen, Login-Sperren und Zähler für Rate-Limits liegen in normalen Variablen im Arbeitsspeicher des Server-Prozesses.

Das hat drei Folgen:

1. Jeder Neustart oder Deploy meldet alle Nutzer ab.
2. Bei Angriffen wachsen diese Strukturen ohne Grenze, bis der Speicher voll ist.
3. Ein zweiter Prozess – die einfachste Art, mehr Last zu verkraften – hätte seine eigenen, widersprüchlichen Sitzungen. Die App lässt sich also nicht einmal auf demselben Server verdoppeln.

Die Lösung ist unspektakulär: Sitzungen und Zähler gehören in die Datenbank oder einen zentralen Speicher wie Redis.

Das fehlende Datenmodell: Benutzer ja, Firmen nein

Viele KI-gebaute Apps kennen nur einzelne Logins. Für ein Produkt, das an Unternehmen verkauft werden soll, fehlt damit die wichtigste Ebene: die Organisation. Sie verbindet:

• mehrere Benutzer einer Firma,
• Rollen wie «Firmen-Admin»,
• Lizenzen bzw. Sitzplätze,
• den Vertragsstatus (Test, aktiv, gekündigt, gesperrt).

Hier liegt oft die eigentliche Skalierungsgrenze. Die Frage ist nicht, ob der Server 500 Accounts aushält – das tut er meist. Die Frage ist, ob das Datenmodell 500 zahlende Firmen abbilden kann. Ohne Organisationsebene lautet die Antwort nein, egal wie stark der Server ist.

Wie viel hält die App wirklich aus?

«Wir haben 300 Accounts, reicht das?» lässt sich nicht aus der Anzahl Accounts beantworten. Entscheidend sind:

• die Anzahl gleichzeitig aktiver Nutzer,
• die Laufzeit der aufwendigsten Abfragen,
• die Last durch Hintergrundjobs wie Importe.

Das misst man mit einem Lasttest, der echte Nutzung nachstellt. Erst danach lohnt es sich, über mehr Server, Caching oder eine andere Datenbank zu entscheiden. Wer vorher investiert, baut oft eine teure Infrastruktur für ein Problem, das er nicht hat.

Der Weg raus: modularisieren statt neu bauen

Die Versuchung ist gross, alles wegzuwerfen und «richtig» neu zu bauen. Davon raten wir fast immer ab. In einem KI-gebauten Prototyp steckt meist wertvolles Fachwissen – Sonderfälle, Regeln, Datenlogik –, das bei einem Neubau aus dem Gedächtnis nachgebaut würde und dabei verloren geht.

Bewährt hat sich diese Reihenfolge:

1. Kritische Logik mit Tests festhalten. Bevor irgendetwas umgebaut wird, beschreiben automatisierte Tests, was die App heute tut. Sie sind das Sicherheitsnetz für alles Weitere.
2. Backend in Schichten zerlegen. API, Geschäftslogik und Datenzugriff werden schrittweise aus der grossen Datei gelöst. Die Datenbank bleibt dabei vorerst, wie sie ist.
3. Zustand auslagern. Sitzungen und Rate-Limits wandern in die Datenbank oder einen zentralen Speicher.
4. Auf PostgreSQL migrieren, mit versionierten Migrationen. Weil die Logik jetzt getrennt ist, ändert sich dabei wenig Code.
5. Frontend in Komponenten zerlegen, die ihre Daten über die neue API beziehen – Ansicht für Ansicht, während die alte Version weiterläuft.
6. Messen, dann skalieren. Monitoring und Lasttests zeigen, wo die echten Grenzen liegen.

Parallel dazu: Monitoring mit Alarmierung, Backups ausserhalb des Produktionsservers und ein einmal wirklich getesteter Restore. Diese drei Punkte kosten wenig und verhindern, dass ein Ausfall erst durch einen Kunden bemerkt wird.

Selbsttest: Wie skalierbar ist Ihre App?

Beantworten Sie diese Fragen ehrlich. Jedes «Nein» ist ein Punkt für die Roadmap.

• Kann ich eine Funktion ändern, ohne Dateien anzufassen, die mit ihr nichts zu tun haben?
• Gibt es automatisierte Tests für die wichtigste Geschäftslogik?
• Liegt die Datenbank auf einem dauerhaften Speicher – und überlebt sie ein neues Deployment?
• Werden Schemaänderungen über versionierte Migrationen gemacht?
• Bleiben Nutzer nach einem Neustart angemeldet?
• Könnte ich morgen einen zweiten Server-Prozess starten, ohne dass etwas kaputtgeht?
• Kennt meine App Firmen mit mehreren Benutzern, Rollen und einem Vertragsstatus?
• Merke ich einen Ausfall, bevor es ein Kunde tut?
• Liegt ein Backup ausserhalb des Produktionsservers, und habe ich es je zurückgespielt?

Mehr als drei «Nein» bei einem Produkt, das bald Geld verdienen soll? Dann lohnt sich ein Blick von aussen – bevor die ersten Kunden den Stresstest übernehmen.