PocketBase: Das Backend für die Hosentasche

Neulich stand ich vor einem klassischen Problem: Ein kleines Projekt brauchte ein Backend — Datenbankzugriff, eine REST-API, User-Authentifizierung, Admin-Interface. Die üblichen Verdächtigen? Firebase macht mich von Google abhängig, Supabase braucht Docker-Compose und PostgreSQL, eine eigene Express/Node-API will gebaut und gewartet werden. Für ein mittelgroßes Projekt alles Kanonen und Spatzen.

Dann bin ich auf PocketBase gestoßen — und war ehrlich gesagt überrascht, wie viel in einer einzigen Binary steckt.

Was ist PocketBase?

PocketBase ist ein Open-Source-Backend, das als eine einzige ausführbare Datei daherkommt. Kein Docker, keine Datenbankkonfiguration, kein Node-Setup. Herunterladen, ausführen, fertig.

Intern verwendet PocketBase SQLite als Datenbank — was sich zunächst unscheinbar anhört, für die meisten Projekte aber vollkommen ausreicht. SQLite ist schneller als viele Entwickler denken und für Single-Writer-Szenarien (also fast alle Web-Apps) absolut produktionsreif.

Was ist alles enthalten?

Eine Menge. Das ist das Bemerkenswerte:

• REST-API — automatisch generiert für alle Collections, inklusive Filter, Sortierung, Pagination
• Echtzeit-Subscriptions — WebSocket-basiert, direkt aus der Box
• Authentifizierung — Email/Passwort, OAuth2 (Google, GitHub, etc.), API-Keys
• Admin-UI — vollständiges Dashboard unter /_/ im Browser
• File-Uploads — mit automatischer Thumbnail-Generierung
• Migrations — versionierte Schema-Änderungen als JavaScript-Dateien
• Hooks / Extensions — erweiterbar in Go oder JavaScript

Das alles in einer Binary, die auf macOS, Linux und Windows läuft.

Schnellstart: 5 Minuten bis zur laufenden API

# Binary herunterladen (Beispiel macOS arm64)
curl -L https://github.com/pocketbase/pocketbase/releases/download/v0.36.8/pocketbase_0.36.8_darwin_arm64.zip -o pb.zip
unzip pb.zip

# Starten
./pocketbase serve

Fertig. PocketBase läuft auf Port 8090:

• Admin-UI: http://localhost:8090/_/
• REST-API: http://localhost:8090/api/

Beim ersten Start legt man einen Superuser-Account an — und kann sofort Collections erstellen, Datensätze anlegen und die API abfragen.

Collections: Datenbank ohne Schema-Schmerz

Im Admin-Dashboard legt man Collections an — vergleichbar mit Datenbanktabellen, aber mit einer freundlicheren UI. Felder wie text, number, email, date, relation, select und file stehen bereit.

Für eine Collection articles mit Titel, Inhalt und Autor reichen zwei Minuten im Browser. PocketBase generiert daraus sofort:

GET    /api/collections/articles/records
POST   /api/collections/articles/records
GET    /api/collections/articles/records/:id
PATCH  /api/collections/articles/records/:id
DELETE /api/collections/articles/records/:id

Inklusive Filter:

GET /api/collections/articles/records?filter=author='Max'&sort=-created

API Rules: Wer darf was?

Jede Collection hat fein granulare Zugriffsregeln. Per einfachem Ausdruck bestimmt man, wer lesen, schreiben, erstellen oder löschen darf:

# Nur eingeloggte User
@request.auth.id != ""

# Jeder (öffentlich)
""  ←  leerer String = allow all

# Nur Admin
null  ←  null = superuser only

Das ist eines der elegantesten Features: Keine Middleware schreiben, keine Auth-Checks im Code — die Regeln sitzen direkt auf der Datenbankebene.

Migrations: Versionskontrolle für das Schema

Schemaänderungen lassen sich als JavaScript-Dateien versionieren und automatisch beim Start anwenden:

// pb_migrations/1_create_articles.js
migrate((app) => {
  const collection = new Collection({
    name: "articles",
    type: "base",
    fields: [
      { name: "title",   type: "text", required: true },
      { name: "content", type: "text", required: false },
    ],
    listRule: "",    // öffentlich lesbar
    createRule: "@request.auth.id != ''", // nur eingeloggt schreiben
  });
  app.save(collection);
}, (app) => {
  // Rollback
  app.delete(app.findCollectionByNameOrId("articles"));
});

Migrations werden automatisch beim serve-Start angewendet — perfekt für CI/CD und containerisierte Deployments.

Im Container: Das Image ist einzeilig

FROM alpine:3.20
RUN apk add --no-cache curl unzip && \
    curl -L "https://github.com/pocketbase/pocketbase/releases/download/v0.36.8/pocketbase_0.36.8_linux_amd64.zip" \
         -o /tmp/pb.zip && \
    unzip /tmp/pb.zip pocketbase -d /pb && \
    chmod +x /pb/pocketbase && \
    rm /tmp/pb.zip && apk del curl unzip
COPY pb_migrations /pb/pb_migrations
EXPOSE 8090
CMD ["/pb/pocketbase", "serve", "--http=0.0.0.0:8090", "--dir=/pb/pb_data", "--migrationsDir=/pb/pb_migrations"]

Ein Container, eine Binary, eine SQLite-Datei auf einem persistenten Volume — das ist das komplette Backend.

Wichtig bei Kubernetes: Deployment-Strategie auf Recreate setzen, nicht RollingUpdate. SQLite erlaubt nur einen Schreiber gleichzeitig — zwei laufende Pods würden sich gegenseitig blockieren.

Praxisbeispiel: Promo-Tool für ein Musiklabel

Ich habe PocketBase kürzlich für Phantom Grid eingesetzt — ein unabhängiges Elektronik-Label. Gebraucht wurde ein Backend für ein token-geschütztes Promo-Tool: DJs bekommen einen persönlichen Link, hören das Release, laden Tracks herunter und geben Feedback.

Drei Collections, 30 Minuten Setup:

• promos — Token, Release-Slug, Empfängername, Ablaufdatum
• feedback — Relation zu promos, Name, Email, Kommentar
• download_events — Logging jedes Downloads

Das Astro-Frontend fragt die PocketBase-API serverseitig ab — keine Auth-Token nötig, weil die Collections entsprechend offen konfiguriert sind. PocketBase läuft als ClusterIP-Service in Kubernetes, ist also gar nicht direkt aus dem Internet erreichbar. Nur das Astro-Node-Backend spricht intern mit PocketBase, der Admin-Bereich ist über eine separate Subdomain geschützt.

PocketBase vs. die Alternativen

Für Projekte, bei denen kein extremes Skalierungsszenario erwartet wird, ist PocketBase unschlagbar einfach.

Wann eignet sich PocketBase?

Gut geeignet für:

• MVPs und Prototypen
• Mittelgroße Web-Apps (Content-Sites, Tools, Interne Apps)
• Projekte, die volle Datenkontrolle benötigen (DSGVO, Self-hosting)
• Headless CMS als leichtgewichtige Alternative
• Backends hinter SSR-Frameworks wie Astro oder Next.js

Weniger geeignet für:

• Hochfrequentes Multi-Writer-Szenario (SQLite-Limit)
• Horizontale Skalierung über mehrere Pods (Single-Writer)
• Komplexe Joins und relationale Queries (PostgreSQL wäre besser)

Fazit

PocketBase ist das, was man sich von einem Backend wünscht: Es funktioniert sofort, kommt ohne Overhead und macht genau das, was es verspricht. Die Lernkurve ist flach, die Dokumentation gut, die Community wächst.

Für alle, die schnell ein Backend brauchen ohne sich mit Infrastructure zu beschäftigen — und das Ergebnis trotzdem selbst hosten wollen — ist PocketBase 2026 eine der besten Optionen im Ökosystem.

Ein direktes Ausprobieren lohnt sich: pocketbase.io