PocketBase – Erfahrungen aus LingoDeck

Ich habe PocketBase für LingoDeck verwendet, eine Karteikarten-App zum Sprachenlernen mit Spaced Repetition, KI-generierten Karten und Vorlesefunktion. Das Frontend ist eine Nuxt-4-App, als Backend läuft PocketBase 0.30 mit dem JavaScript-SDK. Zeit für ein ehrliches Fazit.

Was ist PocketBase?

PocketBase ist ein Open-Source-Backend (MIT-Lizenz), das aus einer einzigen ausführbaren Datei besteht. Sie ist in Go geschrieben und bringt alles Wichtige mit:

• eine SQLite-Datenbank, die als Datei neben dem Programm liegt
• eine REST-API für jede Collection, dazu Realtime-Abonnements
• Authentifizierung mit E-Mail und Passwort, OAuth2 und mehr
• Dateiuploads, lokal oder in einem S3-Speicher
• ein Admin-Panel, in dem Collections, Felder, Zugriffsregeln, Logs und Einstellungen verwaltet werden
• Hooks und Migrationen in JavaScript (alternativ lässt sich PocketBase als Go-Framework erweitern)

Man startet die Datei mit ./pocketbase serve und hat ein fertiges Backend. Für das Frontend gibt es SDKs für JavaScript und Dart. In der App sprechen die Nuxt-Seiten und der Nuxt-Server über das JS-SDK mit PocketBase. Realtime und OAuth habe ich bisher nicht gebraucht.

Vorteile

Moderne Oberfläche

Das Admin-Panel ist schnell, aufgeräumt und für ein Backend, das man in einer Minute installiert hat, erstaunlich vollständig. Auf dem Screenshot sieht man die Collection cards mit Suche und Filter. Auch sonst ist alles an einem Ort:

• Collections und Felder mit Typen wie Text, Zahl, Select, Relation, JSON, Datei und Autodate
• Zugriffsregeln als Ausdruck pro Aktion (List, View, Create, Update, Delete), mit Editor und Autovervollständigung
• API Preview, die für jede Collection fertige Beispielanfragen zeigt
• Logs und Statistiken der Anfragen
• Einstellungen für Mailversand, Dateispeicher und automatische Backups

Die Oberfläche richtet sich allerdings an Entwickler. Für Redakteure, die Texte pflegen, ist sie kein Ersatz für ein klassisches CMS. Dazu später mehr.

Anpassungsfähigkeit

Das Datenmodell ist frei, und die Zugriffsregeln sind mächtiger, als sie auf den ersten Blick aussehen. Jede Collection hat fünf Regeln (List, View, Create, Update, Delete), und jede davon ist ein kurzer Ausdruck. Nutzer dürfen zum Beispiel nur ihre eigenen Datensätze sehen und anlegen:

notes.listRule   = 'owner = @request.auth.id'
notes.createRule = '@request.auth.id != "" && owner = @request.auth.id'

Oder Inhalte sind öffentlich lesbar, geändert werden dürfen sie aber nur von angemeldeten Nutzern, die den Datensatz selbst angelegt haben:

articles.listRule   = ''
articles.updateRule = '@request.auth.id != "" && author = @request.auth.id'

Eine leere Regel bedeutet „für alle“, null bedeutet „nur Superuser“.

Es gibt keine Middleware und keinen Endpoint, der das prüft. PocketBase wertet die Regeln bei jeder Anfrage selbst aus, auch wenn jemand die API direkt anspricht. Das spart eigene Berechtigungslogik.

Wenn die Regeln nicht reichen, gibt es mehrere Wege:

• JS-Hooks und eigene Routen (pb_hooks) direkt im Programm
• Go-Erweiterung, wenn man PocketBase als Framework in ein eigenes Go-Projekt einbindet
• Eigener Server davor. Ein Nuxt- oder Node-Server kann das Login über auth-refresh prüfen und danach externe APIs aufrufen, deren Schlüssel nicht im Browser landen sollen.

Die Grenze ist das Admin-Panel. Es lässt sich nicht erweitern. Es gibt keine eigenen Views, Dashboards oder Felder im Backend. Wer zum Beispiel eine eigene Nutzerverwaltung oder ein Dashboard braucht, muss es selbst in der App bauen, und für Kunden würde ich PocketBase nicht ohne eine eigene Oberfläche einsetzen. Bei Payload oder Statamic ist das einfacher.

KI-Kompatibilität

Hier gibt es Licht und Schatten. Positiv ist, dass sich fast alles als Text beschreiben lässt:

• Migrationen sind JavaScript-Dateien im Repository. Collections, Felder, Indizes und Regeln sind damit als Git-Diff nachvollziehbar, und ein Assistent kann neue Migrationen schreiben.
• Regeln sind kurze Ausdrücke. Man kann sie lesen, prüfen und per Prompt ändern.
• Die API ist klein. Das SDK besteht im Wesentlichen aus getFullList, getList, create, update und delete, dazu filter, sort und expand.
• Für die Hooks bringt PocketBase eine Typdatei (types.d.ts) mit, die der Editor und der Assistent nutzen können.

Weniger gut: Die Wahrheit über das Schema steckt in der Datenbank, nicht im Code. Im Gegensatz zu einem Code-First-System wie Payload sieht ein Assistent das Schema nur, wenn die Migrationen vollständig sind. Und die Wahrscheinlichkeit, dass er veralteten Code erzeugt, ist real. PocketBase hat sich mit Version 0.23 stark verändert, und viele Beispiele im Netz gehören noch zur alten API. Bei mir waren die ersten Migrationen gegen eine ältere Version geschrieben. Die Folge war, dass created und updated fehlten und eine Sortierung nach -updated mit einem 400-Fehler abbrach. Eine zusätzliche Migration hat das repariert.

Mein Fazit: gut geeignet, solange man die Migrationen im Repository pflegt und dem Assistenten die verwendete Version mitgibt. Bei mir steht sie, zusammen mit den Regeln und Besonderheiten, in der AGENTS.md.

Deployment

Das ist für mich der größte Vorteil. Ein Deployment besteht aus einer Datei, und bei mir läuft es so:

1. GitHub Actions baut die Nuxt-App und lädt sie auf den Server.
2. Die Dateien aus pb_migrations/ werden hochgeladen.
3. PocketBase wird per pm2 neu gestartet und wendet beim Start alle neuen Migrationen an.
4. Ein Health-Check (/api/health) bestätigt, dass es wieder läuft.

Es gibt keine Datenbank, die separat installiert und gewartet werden muss, und keine Abhängigkeiten, die gebaut werden müssen. Updates von PocketBase selbst sind ebenfalls eine neue Datei (./pocketbase update). Auch der Betrieb ist einfach: PocketBase lauscht auf 127.0.0.1:8090, nginx leitet /pb dorthin und übernimmt SSL.

Zwei Dinge sollte man beachten:

• Beim Neustart ist PocketBase kurz nicht erreichbar. Für eine App dieser Größe ist das unkritisch.
• Änderungen im Admin-Panel auf dem Server erzeugen automatisch Migrationsdateien, aber eben dort und nicht im Repository. Wer Collections lieber im Panel klickt, muss die generierten Dateien anschließend vom Server herunterladen und ins Projekt übernehmen. Ich schreibe Migrationen deshalb bevorzugt von Hand. Auch Einstellungen wie die Gültigkeit des Login-Tokens (30 statt 7 Tage) stehen in einer Migration. Eine Änderung nur im Panel würde sonst bei einem frischen pb_data verloren gehen.

Wenig Ressourcen und kostenlos

Die Datei ist rund 32 MB groß. Auf meinem Rechner belegte der Prozess mit rund 500 Datensätzen etwa 60 MB Arbeitsspeicher. Es gibt keine Lizenz, keine Preise pro Nutzer und keine Beschränkung auf ein Projekt. Dafür muss man sich um Server und Backups selbst kümmern.

Nachteile

Serveranforderungen

Hier muss man unterscheiden. Die Anforderungen sind gering, aber PocketBase ist kein statisches Hosting. Es braucht:

• einen dauerhaft laufenden Prozess, bei mir mit pm2
• persistenten Speicher für den Ordner pb_data mit Datenbank und Uploads
• einen Reverse Proxy für HTTPS
• Shared Hosting ist damit raus. Ein kleiner VPS reicht aber aus, und PocketBase teilt sich bei mir den Server mit der Nuxt-App.

Verglichen mit einem Node-basierten CMS ist das ein Vorteil, verglichen mit einem Baukasten oder statischen Seiten ein Nachteil. Dazu kommt, dass SQLite genau einen Schreibzugriff gleichzeitig zulässt und sich nicht auf mehrere Server verteilen lässt. Für eine App mit einem Server ist das kein Problem. Wer horizontal skalieren will, hat mit PocketBase aber ein Problem.

Kein echtes SQL

Das stimmt nur zum Teil, deshalb eine genauere Einordnung. Unter der Haube ist PocketBase echtes SQL, denn die Daten liegen in einer SQLite-Datei. Der Zugriff von außen läuft aber nicht über SQL, sondern über die eigene API mit einer eigenen Filter-Syntax:

const defaults = await pb.collection('cards').getFullList({
  filter: 'owner = ""',
})

const progress = await pb.collection('card_progress').getFullList({
  expand: 'card',
})

Das ist für die meisten Abfragen angenehm, aber nicht mehr als das, was die API anbietet:

• Joins gibt es nur über Relationen und expand.
• Auswertungen mit GROUP BY, Summen oder Zählungen sind über die API nicht möglich.
• Wer ein anderes Tool anbinden will, kann sich nicht einfach mit einer Datenbank verbinden. Die Datei gehört PocketBase, und ein zweiter Zugriff von außen ist keine gute Idee.

Es gibt Auswege. View Collections definiert man selbst mit einem SQL-SELECT, sie sind schreibgeschützt, lassen sich aber wie jede andere Collection abfragen. In den Hooks kann man außerdem rohes SQL ausführen. Wer von Anfang an mit Joins, Berichten und komplexen Abfragen rechnet, sollte stattdessen eine klassische Datenbank wie Postgres wählen. PocketBase unterstützt keine andere Datenbank als SQLite.

Der Stand vor Version 1.0

PocketBase ist weiterhin Version 0.x. Das Projekt weist selbst darauf hin, dass die Abwärtskompatibilität vor 1.0 nicht garantiert ist. Der Umstieg auf 0.23 hat das gezeigt: Collections und Migrationen wurden umgebaut, und alte Beispiele funktionieren nicht mehr. Mit eigenen Migrationen und festen Versionen ist das beherrschbar, ein Update sollte man trotzdem bewusst einplanen und nicht beim nächsten Deploy nebenbei mitnehmen.

Dazu kommt, dass PocketBase im Wesentlichen von einer einzelnen Person betreut wird. Das Projekt ist sehr aktiv und stabil, trotzdem muss man bei einem langlebigen Produkt mit diesem Risiko leben. Weil die Daten in einer SQLite-Datei liegen und die API-Regeln lesbar sind, wäre ein späterer Umzug aber möglich.

Daten und Backups liegen nicht im Repository

Wie bei jedem Backend mit Datenbank gehören die Inhalte nicht zu Git. Die Migrationen beschreiben nur die Struktur. Startet PocketBase ohne den Ordner pb_data, in dem die Datenbank liegt (auf einem neuen Rechner oder einem neu aufgesetzten Server), beginnt es mit einer leeren Datenbank. Die Migrationen legen dann die Struktur an, aber keine Inhalte, und die App startet mit leeren Collections.

PocketBase kann zwar automatisch Backups erstellen, auch in einen S3-Speicher, aber das muss man einrichten und gelegentlich testen. Ein Backup ist erst dann eins, wenn man es zurückspielen kann.

Kleine Stolpersteine

• Regeln vergleichen Text exakt. Ein Vergleich mit [email protected] trifft nicht auf [email protected] zu. E-Mail-Adressen sollte man deshalb schon im Formular kleinschreiben.
• E-Mail-Adressen sind standardmäßig unsichtbar. PocketBase gibt sie nur dem Besitzer des Datensatzes zurück. Für die Nutzerliste im Admin-Bereich musste ich emailVisibility setzen.
• Ohne SMTP keine Mails. Solange kein Mailserver konfiguriert ist, kann PocketBase weder Bestätigungs-Mails noch Passwort-Resets verschicken.

Fazit

PocketBase passt gut zu kleinen bis mittleren Apps mit Login, Nutzerdaten und klaren Zugriffsregeln, vor allem wenn man das Backend selbst betreibt und möglichst wenig Infrastruktur will. Das Admin-Panel ist modern, die Regeln sparen viel Backend-Code, und das Deployment ist so einfach, wie es bei einem Backend mit Datenbank sein kann. Mit Migrationen im Repository arbeiten auch KI-Assistenten gut damit.

Die Nachteile sind real: Es gibt kein SQL über die API, das Admin-Panel lässt sich nicht erweitern, die Skalierung ist auf einen Server begrenzt, und mit Version 0.x muss man Updates sorgfältig planen. Für Projekte, in denen Redakteure Inhalte pflegen, würde ich ein CMS wie Payload oder Statamic wählen. PocketBase ist ein interessantes Produkt, aber für ein neues Projekt würde ich mich für ein anderes System wie Payload oder Appwrite entscheiden.