Die Eine-Datei-Philosophie

PocketBase und Beszel behaupten dasselbe: maximale Funktionalitaet bei minimaler Betriebskomplexitaet. Ein Binary, ein Container, fertig. Dieser Report prueft die Behauptung — und rechnet sie gegen deinen tatsaechlichen Bestand auf maierzone.de durch.

Erstellt

2026-08-06

Ausloeser

github.com/pocketbase/pocketbase

Referenzfall

henrygd/beszel — PocketBase als Fundament einer echten Anwendung

Bezugssystem

VPS maierzone.de · Matroshka · mzone-publisher

Verdikt

Selektiv uebernehmen. Als Werkzeug ja, als Doktrin nein.

1 · Die These in einem Satz

2 · Was da technisch wirklich steht

3 · Warum das gerade jetzt zieht

Schematisches Modell, keine Messreihe. Waagerecht: wachsende Anforderungen (Teams, Schreiblast, Verfuegbarkeitsziele). Senkrecht: Gesamtaufwand aus Bau plus Betrieb. Die Frage fuer jedes Projekt lautet nicht welche Kurve besser ist, sondern: Wo auf der Achse stehe ich realistisch — heute und in zwei Jahren?

4 · Realitaetscheck — wo die Philosophie bricht

Der Trend wird ueberwiegend von Leuten beschrieben, die ihn gerade begeistert entdeckt haben. Fuenf Punkte, die in den Begeisterungstexten fehlen.

1. R-01 SQLite hat genau einen Schreiber
   WAL-Modus erlaubt beliebig viele parallele Leser, aber Schreibvorgaenge werden serialisiert. Fuer Lese-dominierte Anwendungen ist das voellig unkritisch. Sobald du echte Schreiblast hast — viele Nutzer, die gleichzeitig Daten aendern — ist es eine harte Wand, und zwar eine, gegen die du erst im Betrieb faehrst. Das ist kein Fehler, das ist eine Designentscheidung. Aber sie ist nicht verhandelbar.
2. R-02 Vier Jahre, 263 Releases, immer noch vor 1.0
   Das Projekt sagt selbst, dass volle Rueckwaertskompatibilitaet vor 1.0 nicht garantiert ist. Fuer ein privates Projekt ist das verkraftbar. Aber es heisst: Du kaufst dir eine wiederkehrende Migrationspflicht ein, und du kaufst sie bei einem Projekt, das im Wesentlichen von einer Person getragen wird. Rechne das in die Betriebskosten ein, die du gerade sparen wolltest.
3. R-03 Fuer dich ist es ein Sprachbruch
   Das ist dein spezifischer Punkt. PocketBase erweiterst du in Go oder in der eingebetteten JavaScript-VM — nicht in Java. Deine gesamte Kompetenz in Spring, deine Testroutinen, deine Bibliotheksvertrautheit gelten dort nicht. Bei einem CRUD-Backend, das du ohnehin kaum anfasst, ist das egal. Sobald nennenswerte Fachlogik hineinwandert, hast du dir eine zweite Codebasis in einer Zweitsprache gebaut — und damit exakt die Komplexitaet zurueckgekauft, die du streichen wolltest.
4. R-04 Keine Vektorsuche, keine Erweiterungen ohne Sonderbau
   Der SQLite-Treiber ist reines Go — das ist der Grund fuer die statische Verlinkung, und zugleich der Grund, warum C-Extensions nicht einfach dazugeladen werden. Fuer Matroshka ist damit entschieden: pgvector hat keine bequeme Entsprechung. Wer semantische Suche braucht, bleibt bei PostgreSQL.
5. R-05 Eine Datei heisst nicht wenig Kopplung
   Der gefaehrlichste Denkfehler in diesem Trend. Microservices machen Kopplung sichtbar, indem sie sie an Netzwerkgrenzen zwingen. Ein Binary macht Kopplung unsichtbar — sie ist weiterhin da, nur nicht mehr im Betriebsdiagramm. Der Trend loest ein Betriebsproblem, kein Architekturproblem. Wer beides verwechselt, baut in zwei Jahren einen grossen Ball Schlamm und wundert sich, warum die Vereinfachung nichts gebracht hat.

5 · Wieviel laeuft eigentlich dauerhaft?

Anzahl dauerhaft laufender Prozesse je Deployment. Die geplanten Staende (Matroshka, Wiki) sind aus deinen Architekturentscheidungen abgeleitet, MZP ist geschaetzt. Die Zahl selbst ist nicht das Problem — das Problem ist, dass jeder dieser Prozesse Speicher belegt, ein Update braucht und dir bei einem Ausfall um 3 Uhr nachts erklaert werden will.

6 · Anwendung auf deinen Bestand

Erwarteter Nutzen eines gemeinsamen PocketBase-Backends, 0 bis 10. Bewertet wird nicht, ob es technisch ginge — es ginge fast ueberall — sondern ob es dir tatsaechlich Arbeit abnimmt.

Der eine Zug, der sich sofort rechnet

7 · Der ehrlichere Transfer: Eine-Datei in Java

8 · Empfohlene Reihenfolge

1. S-01 Beszel deployen — diese Woche
   Ein Container, ein Agent, ein Nginx-Block auf einer neuen Subdomain. Kosten: unter einer Stunde. Nutzen: du weisst ab dann, was auf deinem VPS wirklich passiert, statt es aus Stacktraces zu rekonstruieren. Nebenbei hast du ein reales, laufendes Beispiel der Philosophie zum Anfassen.
2. S-02 Eine PocketBase-Instanz als gemeinsames Backend erproben
   Nicht sieben Instanzen — eine, mit einer Collection je Anwendung. Fang mit whiteboard an, weil dort die Realtime-Subscriptions den groessten Effekt haben und du diesen Teil sonst selbst bauen muesstest. Wenn es traegt, ziehen calendar und words nach. Wenn nicht, hast du eine Datei geloescht und nichts verloren.
3. S-03 Den Matroshka-Compose-Stack durchrechnen — nicht umbauen
   App, PostgreSQL, Keycloak, SearXNG, Ollama. Frage je Dienst: Was genau bricht, wenn er weg ist? Bei PostgreSQL und Ollama ist die Antwort klar. Bei Keycloak haengt sie daran, ob er ohnehin fuer andere Dienste laeuft. Das Ergebnis ist eine bewusste Entscheidung — und die ist mehr wert als jede Streichung aus Prinzip.
4. S-04 MZP: Native Image evaluieren, Architektur unangetastet lassen
   Der Metaspace-Absturz war ein Symptom, kein Architekturfehler. Falls er wiederkehrt, ist ein Classloader-Leak beim Template-Rendering die wahrscheinlichere Ursache als zu wenig Speicher — und Native Image wuerde die Klasse von Problem strukturell entfernen.

9 · Die Fragen, die du dir stellen solltest