Plattform
Backend: ein Supabase-Fundament für ernsthafte KI-Softwarelieferung
Authentifizierung, eine echte Postgres-Datenbank, Dateispeicher und Row-Level Security kommen mit deiner App — nicht als separates Projekt, das du erst verdrahten musst.
Das Ciao-Backend ist Supabase-gestützt: Authentifizierung, eine Postgres-Datenbank, Dateispeicher, Row-Level Security und APIs, generiert zusammen mit deiner Anwendung. Anders als tabellenkalkulationsgestützte App-Builder gibt Ciao jedem Projekt eine echte relationale Datenbank mit an der Datenbank selbst durchgesetzten Zugriffsregeln — Standard-Infrastruktur, die deine Ingenieure prüfen und abfragen können, und die dir zusammen mit dem Rest des Codes gehört.
Veröffentlicht 2026-07-03 · Zuletzt aktualisiert 2026-07-03
Echte Apps brauchen eine echte Datenschicht
Jede ernsthafte Anwendung ist eine Datenbank mit einer Benutzeroberfläche. Die Datenschicht ist auch, wo App-Builder üblicherweise Abstriche machen: Tabellenkalkulationen als Speicher, Login angeflanscht, Berechtigungen als Hoffnung. Es funktioniert in der Demo — und dann taucht ein zweites Team, echte Kunden oder ein Prüfer auf.
Ciao gibt jeder Anwendung ein Supabase-gestütztes Backend: Authentifizierung, eine Postgres-Datenbank, Dateispeicher, Row-Level Security und APIs — generiert zusammen mit der Anwendung und mit ihr wachsend. Es ist die Infrastruktur, die Ingenieure bewusst wählen würden, nur ohne die Einrichtung. Und weil sie mit der Anwendung ankommt, driften Datenmodell und Oberfläche nie auseinander — eines beschreibt das andere.
Wie das Backend zusammenkommt
Das Backend wird zusammen mit der Anwendung generiert und wächst durch denselben Kreislauf.
1. Die Daten in einfacher Sprache beschreiben
„Kunden haben Abonnements; Rechnungen gehören Kunden“ wird zu einem relationalen Schema in Postgres, mit richtigen Typen und Beziehungen.
2. Authentifizierung wird eingebunden
Anmeldung, Sitzungen und Nutzerverwaltung existieren von Anfang an, weil Auth das Fundament ist, auf dem jede Zugriffsregel aufbaut.
3. Row-Level Security setzt durch, wer was sieht
Zugriffsregeln leben in der Datenbank selbst: Die Abfragen eines Nutzers können nur die Zeilen berühren, die die Richtlinie erlaubt, selbst wenn sich ein Fehler in den Anwendungscode einschleicht.
4. Storage kümmert sich um die Dateien
Uploads, Dokumente und Bilder bekommen ein Zuhause mit denselben angewendeten Zugriffsregeln — kein öffentlicher Bucket, den jemand später sperren wollte.
5. APIs legen die Daten offen
Generierte Endpunkte lassen deine Anwendung — und deine Integrationen — kontrolliert und konsistent mit den Daten arbeiten.
6. Das Schema entwickelt sich unter Governance
Änderungen kommen als Migrationen auf Branches an, durch Prüfung und QA-Gates, sodass die Datenschicht mit dem Produkt mitwächst, statt gegen es zu kämpfen.
Warum es wichtig ist
Row-Level Security ist das Detail, bei dem es sich zu verweilen lohnt. Berechtigungsprüfungen auf Anwendungsebene scheitern offen: eine vergessene Bedingung, und Daten lecken. Row-Level Security scheitert geschlossen — die Datenbank verweigert, was die Richtlinie nicht erlaubt. Ciaos Security-Ebene testet diese Grenzen dann gegen die Live-Anwendung, sodass „die Berechtigungen funktionieren“ getestet wird, nicht angenommen.
Und weil es Supabase und Postgres ist — Standard, weit verbreitete Infrastruktur —, ist nichts an deiner Datenschicht proprietär. Ingenieure können sie direkt abfragen, und wenn du die Anwendung exportierst, gehen Schema und Datenmodell mit. 100 % Eigentum schließt das Backend ein.
Das Backend ist auch, wo KI-gestützte Entwicklung am meisten Disziplin braucht, weil Daten Funktionen überdauern. Bildschirme werden neu gebaut; Schemas sammeln sich an. Die Datenschicht durch kontrollierte Migrationen zu generieren — geprüft, getestet, protokolliert — bedeutet, dass die Datenbank fünfhundert Änderungen später noch ein Schema ist, das jemand lesen kann, keine Ausgrabungsstätte mit einer Login-Seite.
Wer es nutzt
Eine echte Datenschicht verändert, worauf sich jede Rolle verlassen kann.
- Nicht-Ingenieure — Sie bekommen eine korrekte Datenschicht — echtes Schema, durchgesetzte Berechtigungen —, ohne wissen zu müssen, was das ist.
- Ingenieure — Standard-Postgres, das sie prüfen und abfragen können, ohne eine proprietäre Speicher-Engine, die beim Export überrascht.
- Agenturen — Jeder Kunden-Build steht auf demselben zuverlässigen Fundament, statt auf dem, was der Wochenplan improvisiert hat.
- Regulierte Teams — Durchgesetzte Zugriffsregeln, getestete Grenzen und ein Audit-Protokoll — die Datenschicht-Geschichte, nach der Compliance tatsächlich fragt.
Hinweise zu Sicherheit und Governance
- ✓ Row-Level Security setzt Zugriff an der Datenbank durch, nicht nur in der Oberfläche.
- ✓ Zugriffskontroll-Proben von Ciao Security testen diese Regeln gegen die Live-App.
- ✓ Schemaänderungen werden als Migrationen durch Branches, Prüfung und QA-Gates ausgeliefert.
- ✓ Rollenbasierte Zugriffskontrolle regelt, wer die Datenschicht ändern kann.
- ✓ Dateispeicher erbt dieselben Zugriffsregeln wie die Daten, zu denen er gehört.
- ✓ Kundencode wird nicht zum Training von Modellen verwendet; Inferenz läuft unter Zero-Retention-Modellverträgen.
- ✓ Das Schema ist Standard-Postgres — jederzeit mit deiner Anwendung exportierbar.
Was jedes Ciao-Backend umfasst
Alles in dieser Tabelle wird mit jedem Projekt ausgeliefert — nichts davon ist ein Upgrade.
| Funktion | Was du bekommst |
|---|---|
| Authentifizierung | Anmeldung, Sitzungen und Nutzerverwaltung, von Anfang an in die App eingebunden |
| Postgres-Datenbank | Ein echtes relationales Schema, generiert aus Beschreibungen in einfacher Sprache |
| Dateispeicher | Uploads und Dokumente mit denselben angewendeten Zugriffsregeln |
| Row-Level Security | Zugriff, durchgesetzt von der Datenbank selbst, getestet gegen die Live-App |
| APIs | Generierte Endpunkte für deine Anwendung und ihre Integrationen |
Häufig gestellte Fragen
Ist das Backend an Ciao gebunden?
Nein. Es ist Supabase-gestützt, Standard-Postgres, und der Export deiner Anwendung schließt Schema und Datenmodell ein. Es gibt keine proprietäre Speicher-Engine zwischen dir und deinen Daten.
Was ist Row-Level Security in der Praxis?
Richtlinien, die in der Datenbank leben und pro Zeile entscheiden, was jeder Nutzer lesen oder schreiben darf. Wenn der Anwendungscode einen Fehler hat, verweigert die Datenbank trotzdem Abfragen, die die Richtlinie nicht erlaubt — Berechtigungen scheitern geschlossen statt offen.
Können unsere Ingenieure direkt mit der Datenbank arbeiten?
Ja — es ist Standard-Postgres, sodass sie es mit den Tools prüfen und abfragen können, die sie bereits nutzen. Schemaänderungen laufen weiterhin durch kontrollierte Migrationen, sodass direkter Zugriff nicht zu undokumentierter Änderung wird.
Können wir bestehende Daten in eine Ciao-App bringen?
Ja — beschreibe die Form dessen, was du hast, und das Schema wird gebaut, um es aufzunehmen, mit Imports, die als Teil des Builds gehandhabt werden. Für größere oder sensiblere Migrationen sprich zuerst mit dem Team.
Wie interagiert das Backend mit Sicherheitstests?
Zugriffskontroll-Proben versuchen mandantenübergreifende Lese- und Schreibvorgänge gegen die Live-Anwendung — die Row-Level-Security-Richtlinien werden getestet, nicht nur geprüft. Die Ergebnisse fließen in das Safe-to-Publish-Dashboard.