PocketBase

Was PocketBase tatsächlich ist

Die meisten Backends sind Montagearbeit: irgendwo eine Datenbank, daneben ein Authentifizierungsdienst, ein Objektspeicher für Uploads, eine kleine Admin-Oberfläche, die man immer bauen wollte, und der Klebstoff dazwischen. PocketBase schrumpft das auf einen Prozess und eine Datei auf der Platte. Sie laden eine ausführbare Datei für Ihre Plattform herunter, starten sie, öffnen die Oberfläche im Browser, definieren Ihre Sammlungen — und Ihre Anwendung hat eine API. Keine Container-Orchestrierung, keine verwaltete Datenbank, kein separater Auth-Anbieter und nichts zu konfigurieren, bevor die erste Anfrage funktioniert.

Der Tausch ist sichtbar und gewollt. Weil die Datenbank eingebettet statt über das Netz erreichbar ist, ist das gesamte Backend ein Prozess, der eine SQLite-Datei hält. Genau das macht den Betrieb so einfach — und macht horizontale Skalierung zu einem anderen Gespräch als anderswo. Für die Phase, in der die meisten Leser dieser Seite stecken — eine Anwendung noch ganz ohne Nutzer oder mit ein paar hundert — steht dieser Tausch deutlich auf Ihrer Seite, und er bleibt es viel länger, als man erwartet.

• Eine eingebettete Datenbank mit Echtzeit-Abos. SQLite in der Binärdatei, dazu eine Abo-API, damit Clients Änderungen erhalten, während sie passieren, statt danach zu fragen. Eine sich selbst aktualisierende Oberfläche wird zur Voreinstellung statt zum Projekt.
• Nutzer und Dateien, eingebaut. Authentifizierung und Nutzerverwaltung sind dabei, ebenso die Handhabung von Dateien. Die zwei Funktionen, die am ersten Tag sonst einen Drittanbieter ins Spiel bringen, sind also schon da.
• Eine Admin-Oberfläche und eine REST-artige API. Eine Weboberfläche zum Definieren von Sammlungen, Bearbeiten von Datensätzen und Prüfen von Daten, darunter eine HTTP-API, die die offiziellen SDKs umschließen. Das JavaScript-SDK deckt Browser, Node.js und React Native ab; für Flutter und Desktop gibt es ein Dart-SDK.
• Eine einzige portable ausführbare Datei. Die vorgefertigten Binärdateien nutzen einen SQLite-Treiber in reinem Go und werden mit deaktiviertem CGO gebaut, lassen sich also für eine veröffentlichte Liste von Linux-, macOS-, Windows-, FreeBSD-, OpenBSD- und NetBSD-Zielen cross-kompilieren. Deployment heißt: eine Datei kopieren und starten.

Zwei Wege, es zu betreiben — und die Wahl zählt später

Der erste Weg ist die eigenständige Anwendung. Release für Ihre Plattform laden, entpacken, den serve-Befehl ausführen, fertig. Die vorgefertigten Binärdateien bringen zusätzlich eine JavaScript-VM mit, sodass Sie Hooks und eigene Endpunkte in JavaScript ergänzen können, ohne Go anzufassen oder irgendetwas neu zu bauen. Das ist der Weg, der heute Nachmittag einen Prototyp vor jemanden stellt, und dabei zu bleiben ist völlig vernünftig.

Der zweite Weg ist die Go-Bibliothek. Sie binden PocketBase in ein eigenes Go-Programm ein, registrieren Routen und Geschäftslogik an dessen Lebenszyklus-Ereignissen und kompilieren das Ergebnis — Ihren Code und das gesamte Backend — zu einer statisch gelinkten ausführbaren Datei. Das minimale Beispiel in der README umfasst rund fünfzehn Zeilen. Der Grund, das am ersten Tag zu wissen, ist der Notausgang: Die eigenständige Anwendung wird nicht zur Wand, wenn Ihre Logik über Konfigurierbares hinauswächst, weil dasselbe Projekt auch das Framework darunter ist. Die Anforderungen sind bescheiden, aktuell Go 1.27 oder neuer zum Bauen.

Wo es in den Wachstumsstack eines Gründers passt

PocketBase ist ein Werkzeug zum Bauen, nicht zum Wachsen, sein Beitrag zum Wachstum ist also indirekt — und das sollte man ehrlich benennen: Es entfernt die Wochen zwischen einer Idee und etwas, in das sich ein Fremder einloggen kann. Das zählt, weil fast nichts von dem, was man über Nachfrage lernen kann, vor diesem Punkt verfügbar ist. Was es nicht tut, ist irgendjemanden zu dem zu bringen, was Sie gebaut haben.

• Für eine erste funktionierende Version. Auth, Speicher und Datenbank in einem Download sind der kürzeste ehrliche Weg vom Prototyp zu etwas, vor das Sie ein echtes Login stellen können. Wenn Sie das Frontend mit KI-Werkzeugen bauen, übernimmt wie vermarkte ich eine per Vibe Coding gebaute App am besten dort, wo das Bauen aufhört.
• Für interne Werkzeuge, für die Sie nicht zahlen wollen. Eine Warteliste, ein Redaktionsplan, ein Outreach-Tracker, ein leichtgewichtiges CRM für Ihre ersten fünfzig Gespräche. Sammlungen plus Admin-Oberfläche decken davon erstaunlich viel ab, ohne selbst zu einem Produkt zu werden, das gepflegt werden muss.
• Neben der Wachstumsebene, nicht an deren Stelle. Nichts davon schreibt Ihre Positionierung, veröffentlicht etwas oder antwortet einem Kunden. Sobald das Produkt existiert, ändert die Arbeit vollständig ihre Gestalt — wie bekomme ich meine ersten 100 Nutzer ist das nächste Problem, und es ist das schwerere.
• Wissen, was Sie sich einhandeln. Die Lizenz ist MIT, und die README erlaubt kommerzielle Nutzung ausdrücklich, einschließlich des Verkaufs eines darauf gebauten Dienstes. Es ist zugleich vor 1.0 mit zu erwartenden brechenden Änderungen, und das Repository beschränkt Pull Requests wegen einer Welle minderwertiger automatisierter Einreichungen vorübergehend auf bestehende Mitwirkende — rechnen Sie also damit, Issues statt Patches einzureichen.

Was wir gelernt haben, als wir SQLite in Produktion betrieben

Wir sind hier nicht neutral, und genau das ist der nützliche Teil: AgentCeres betreibt SQLite ebenfalls in Produktion, das Folgende ist also eine Entscheidung, die wir getroffen haben, und keine Rezension von außen. Das Wichtigste, was ein Ein-Datei-Backend ändert, ist, dass der Ort, an dem diese Datei liegt, zu Ihrer gesamten Architektur wird. Unsere lag auf einem eingehängten Volume, und der Fehler, dem wir immer wieder begegneten, war: Alles, was ein Container geschrieben hatte und was niemand in dauerhaften Speicher geschoben hatte, überlebte das nächste Deployment schlicht nicht. Es meldete sich auch nie als Fehler — es zeigte sich als Anwendung, die still etwas vergessen hatte, und das ist die denkbar schlechteste Art, wie Datenverlust ankommt.

Die zweite Überraschung war, dass das knappe Gut das Volume selbst war und nicht der Platz darauf. Unser Anbieter begrenzt die Zahl der Volumes pro Projekt, und wir stießen weit vor jeder Kapazitätsgrenze an diese Decke, was am Ende eine Neuarchitektur erzwang: Container wurden wegwerfbar, und der dauerhafte Zustand zog in eine Datenbank plus Objektspeicher um, die sie überleben. Wenn Sie ein PocketBase für ein Produkt betreiben, wird Sie das nie berühren. Wenn Sie merken, dass Sie eines pro Kunde wollen, zählen Sie die Volumes, bevor Sie darauf hin entwerfen.

Das dritte ist SQLite-spezifisch und hat uns einen wirklich verwirrenden Nachmittag gekostet. SQLites Typisierung ist flexibel: Wir hatten Zeitstempel in manchen Spalten als Ganzzahl und in anderen als Text gespeichert, und Vergleiche über diese beiden Formen hinweg liefern überhaupt keinen Fehler — nur die falschen Zeilen, stillschweigend, in einer Abfrage, die sich korrekt liest. PocketBase verwaltet sein eigenes Schema, Sie sind davor also weitgehend geschützt, bis Sie anfangen, eigene Abfragen oder eigene Go-Erweiterungen gegen dieselbe Datei zu schreiben — ab da gehört das Problem Ihnen. Legen Sie Ihr Speicherformat einmal fest und prüfen Sie den Spaltentyp, bevor Sie einem Vergleich trauen.