Entwickler untersucht Alternativen zu zentralisierten Cloud-Backends für die Datenhoheit der Nutzer

In einer am 26. Oktober 2026 veröffentlichten Reflexion skizziert der Entwickler Brandon die erheblichen architektonischen Herausforderungen bei der Erstellung von Webanwendungen, die den Besitz der Nutzerdaten in den Vordergrund stellen. Der Autor beschreibt den Versuch, Cheapskate, ein Tool zur Finanzverfolgung, zu entwickeln, ohne sich auf zentrale Backend-as-a-Service-Anbieter wie Supabase zu verlassen. Die Kernspannung besteht darin, nahtlose funktionsübergreifende Gerätefunktionen bereitzustellen und gleichzeitig sicherzustellen, dass sensible persönliche Daten ausschließlich unter der Kontrolle des Nutzers bleiben und nicht auf Servern eines Anbieters gespeichert werden.

Was passiert ist

Der Autor begann mit der Entwicklung von Cheapskate mit dem Ziel, die übliche Praxis zu vermeiden, Authentifizierung und Datenbankverwaltung an Drittanbieterdienste zu übergeben. Während er die Bequemlichkeit von Tools wie Supabase für die Bewältigung von Standardinfrastruktur anerkennt, argumentiert der Entwickler, dass dieses Modell für Anwendungen mit sensiblen Finanzinformationen grundsätzlich fehlerhaft sei. Die zentrale Frage war, ob es möglich ist, das gleiche Maß an Beständigkeit, geräteübergreifender Synchronisation und Freigabefähigkeiten wie in modernen Cloud-Stacks zu liefern, während die Daten lokal beim Nutzer verbleiben.

Um dies zu beantworten, evaluierte der Entwickler systematisch verschiedene technische Ansätze, die behaupten, lokale-first- oder nutzerbesitzte Datenmodelle zu unterstützen. Jede Option wurde anhand spezifischer Kriterien getestet: Einfachheit der Implementierung, geräteübergreifender Zugriff, Freigabefunktionen und Browserunterstützung. Die Untersuchung ergab, dass die meisten bestehenden Lösungen einen Kompromiss erzwingen, indem sie Nutzer in bestimmte Ökosysteme einsperren, ausgereifte Kollaborationsfunktionen vermissen lassen oder technisches Wissen voraussetzen, das weit über das hinausgeht, was typische Endnutzer besitzen. Das Fazit lautete, dass keine aktuelle Off-the-Shelf-Lösung die Bequemlichkeit zentralisierter SQL-Datenbanken für diesen spezifischen Anwendungsfall angemessen ersetzen kann.

Wichtige Details

• localStorage: Abgelehnt, da kein Datenzugriff über mehrere Geräte hinweg unterstützt wird und keine Freigabe mit anderen Nutzern möglich ist.
• showDirectoryPicker: Verworfen aufgrund unvollständiger Browserunterstützung und der Notwendigkeit externer Dienste wie Dropbox für die Dateifreigabe.
• CloudKit Private Database: Ausgeschlossen, da Apple Single Sign-On, ein kostenpflichtiges Entwicklerabonnement erforderlich sind und JavaScript-Bibliotheken für die Freigabe fehlen.
• SQLite in Google Drive: Technisch als sehr mühsam eingestuft für sowohl Entwickler als auch Nutzer, zudem wird eine Abhängigkeit vom Google-Konto erzwungen.
• Bring-your-own DynamoDB: Als funktional, aber unpraktikabel angesehen, da es unzumutbar ist, Nutzer dazu aufzufordern, AWS-Schlüssel für die Anmeldung zu verwalten.
• remoteStorage und CRDTs: Als vielversprechende Konzepte identifiziert, denen derzeit jedoch ausgereifte Tools für Kollaboration und klare Datenschutzgarantien fehlen.

Hintergrund

Backend-as-a-Service (BaaS)-Plattformen wie Supabase sind im modernen Web-Development zum Standard geworden, da sie komplexe Infrastrukturaufgaben abstrahieren. Sie bieten verwaltete Authentifizierung, Echtzeit-Datenbanken und Speicherplatz, sodass sich Entwickler auf die Frontend-Logik konzentrieren können. Diese Bequemlichkeit hat jedoch ihren Preis: Der Dienstanbieter hostet und kontrolliert die zugrunde liegenden Daten. Für Anwendungen mit nicht-sensiblen Daten ist dies selten ein Problem. Bei Finanz- oder Gesundheitsanwendungen bevorzugen einige Entwickler und Nutzer ein Modell, bei dem die Daten auf Geräten liegen, die vom Individuum kontrolliert werden – oft als „local-first“ oder „user-owned“-Architektur bezeichnet.

Local-first-Software zielt darauf ab, Daten auf dem Gerät des Nutzers zu halten und nur bei Bedarf zu synchronisieren. Technologien wie Conflict-free Replicated Data Types (CRDTs) helfen dabei, die Datenkonsistenz über Geräte hinweg zu verwalten, ohne dass ein zentraler Server als einzige Quelle der Wahrheit fungiert. Trotz der theoretischen Vorteile für den Datenschutz ist das Ökosystem für die Entwicklung solcher Anwendungen weniger ausgereift als traditionelle Client-Server-Modelle. Entwickler sehen sich oft mit fragmentierten Tools, inkonsistenten Browser-APIs und einem Mangel an standardisierten Protokollen für sichere Peer-to-Peer-Kollaboration konfrontiert.

Warum es wichtig ist

Für Teams, die selbst gehostete Software betreiben oder Produkte für datenschutzorientierte Märkte entwickeln, hebt diese Analyse eine kritische Lücke in der aktuellen Tooling-Landschaft hervor. Viele Organisationen wählen Self-Hosting, um die Kontrolle über ihre Daten zu behalten, verlassen sich aber dennoch innerhalb ihrer eigenen Infrastruktur auf zentralisierte Architekturen. Die Schwierigkeit, echte nutzerbesitzte Datenmodelle zu implementieren, bedeutet, dass selbst datenschutzorientierte Anwendungen oft dazu neigen, Daten auf Firmenservern zu speichern. Dies schafft Haftungs- und Vertrauensprobleme, da Nutzer davon ausgehen müssen, dass der Betreiber ihre Daten schützt, anstatt kryptografische oder architektonische Garantien für ihren Besitz zu haben.

Das Fehlen eines „Firebase for CRDTs“ oder einer einfachen, universellen API für benutzergesteuerte SQL-Abfragen zwingt Entwickler zu schwierigen Entscheidungen. Sie können entweder komplexe eigene Synchronisierungsschichten bauen, was den Wartungsaufwand und die Fehlerfläche erhöht, oder die Datenschutzkompromisse der zentralisierten Speicherung akzeptieren. Für kleine und mittelständische Unternehmen bedeutet dies, dass die Bereitstellung echter Datensouveränität für Kunden derzeit teurer und technisch riskanter ist als die Nutzung standardmäßiger Cloud-Anbieter. Bis die Tools ausgereift sind, dürften datenzentrische Funktionen eher eine Nischenfähigkeit als ein Standardangebot bleiben.

Was Sie tun können

• Prüfen Sie, ob Ihre Anwendung wirklich Echtzeit-Synchronisation über Geräte hinweg erfordert, bevor Sie sich auf komplexe Local-first-Architekturen festlegen.
• Wenn Sie zentralisierten Speicher nutzen, implementieren Sie strenge Richtlinien zur Datenaufbewahrung und klare Mechanismen für die Nutzerzustimmung, um Datenschutzrisiken zu mindern.
• Beobachten Sie die Entwicklung von remoteStorage- und CRDT-Bibliotheken, da sich diese Ökosysteme schnell weiterentwickeln und bald tragfähige Lösungen bieten könnten.
• Erwägen Sie Hybridmodelle, bei denen sensible Daten clientseitig verschlüsselt werden, bevor sie auf Ihren Servern gespeichert werden, wodurch die Schlüsselkontrolle beim Nutzer bleibt.
• Dokumentieren Sie Ihre Datenarchitektur transparent für die Nutzer und erklären Sie, wo die Daten liegen und wer darauf zugreifen kann.
• Engagieren Sie sich in Open-Source-Communities, die an Local-first-Protokollen arbeiten, um Feedback zu geben und die Reife der Tools zu beschleunigen.