PocketBase, un firebase opensource

60 000 étoiles Github, un seul mainteneur, avant même la V1 !

Lien vers le projet ici.

Un backend complet dans un exécutable de 12Mo. Quatre ans de développement. Une personne aux commandes. Et une documentation qui vous dit noir sur blanc de ne pas l'utiliser sur du critique.

Sur le papier, tous les voyants sont au rouge.

Dans les faits, c'est un des projets open source les plus sains que j'ai regardés cette année. Et ce n'est pas malgré ces contraintes, c'est à cause d'elles.

Ce que fait PocketBase, concrètement

Vous téléchargez un zip d'une douzaine de Mo. Vous le décompressez. Vous lancez le binaire.

unzip pocketbase_0.39.8_linux_amd64.zip
./pocketbase serve

À ce stade vous avez déjà :

• une base SQLite embarquée en mode WAL, avec un schema builder et de la validation
• une API REST générée automatiquement sur vos collections
• de l'authentification email/mot de passe et plus de 15 providers OAuth2
• du temps réel en SSE, avec abonnement par collection ou par enregistrement
• du stockage de fichiers en local ou sur du S3, avec génération de miniatures
• un dashboard d'administration
• du TLS automatique en production

Le tout dans un seul processus.

2 dossiers apparaissent à côté de l'exécutable : pb_data pour vos données et vos uploads, pb_migrations pour les migrations JS de vos collections (celui-là, vous le committez).

Côté client, vous consommez ça avec le SDK JavaScript ou Dart.

import PocketBase from 'pocketbase'

const pb = new PocketBase('http://127.0.0.1:8090')

const list = await pb.collection('articles').getList(1, 50, {
  filter: 'published = true && created > "2026-01-01"',
  sort: '-created',
})

// abonnement temps réel sur toute la collection
pb.collection('articles').subscribe('*', (e) => {
  console.log(e.action, e.record)
})

Et quand le CRUD généré ne suffit plus, vous ne partez pas ailleurs. Vous compilez votre propre binaire en utilisant PocketBase comme framework Go.

package main

import (
    "log"

    "github.com/pocketbase/pocketbase"
    "github.com/pocketbase/pocketbase/apis"
    "github.com/pocketbase/pocketbase/core"
)

func main() {
    app := pocketbase.New()

    // une route maison, protégée par l'auth intégrée
    app.OnServe().BindFunc(func(e *core.ServeEvent) error {
        e.Router.GET("/api/stats", func(e *core.RequestEvent) error {
            return e.JSON(200, map[string]any{"ok": true})
        }).Bind(apis.RequireAuth())

        return e.Next()
    })

    // un hook sur la création d'un article
    app.OnRecordCreateRequest("articles").BindFunc(func(e *core.RecordRequestEvent) error {
        e.Record.Set("slug", slugify(e.Record.GetString("title")))
        return e.Next()
    })

    if err := app.Start(); err != nil {
        log.Fatal(err)
    }
}

Vous recompilez, vous obtenez un binaire, toujours un seul fichier.

C'est ce point précis qui change tout par rapport à un BaaS classique : il n'y a pas de mur entre "ce que la plateforme sait faire" et "ce que je dois recoder ailleurs".

Un parti pris

Je passe beaucoup de temps à lire des pages produit. Celle de PocketBase est une des rares où la FAQ dit majoritairement non.

Voilà ce que le projet refuse explicitement :

• Pas d'hébergement managé. Self-hosted uniquement. La FAQ vous renvoie vers Hetzner, Vultr, ou les tiers gratuits de Google Cloud et Oracle.
• Pas d'autre base que SQLite. Pas de Postgres, pas de MySQL, et aucun plan pour en ajouter.
• Pas de scaling horizontal. Vertical uniquement, sur une seule machine.
• Pas de cloud functions. À la place, vous étendez en Go ou en JS et vous gardez un backend portable.
• Pas de dons. Gani Georgiev, le mainteneur, explique qu'il a arrêté de les accepter parce que la contribution financière d'un individu crée des attentes tacites et une charge mentale de culpabilité quand il ne travaille pas sur la feature du contributeur.
• Pas d'ETA. Il y a une roadmap v1.0, il n'y a pas de dates.
• Pas de PR spontanées. Le README demande de discuter l'implémentation avant, et prévient que même une PR bien faite peut être fermée parce qu'elle décale la planification.

Et le projet précise qu'il n'est ni une startup ni une entreprise. Pas d'équipe payée, pas de société derrière. Un projet open source personnel, en MIT, avec un périmètre volontairement limité.

Un projet qui dit non à tout ça n'a aucune raison de pivoter, aucune raison de changer sa licence, aucune raison d'introduire un plan payant l'année prochaine. Il n'a pas d'investisseurs à rembourser.

Pas de LLM

2 détails que j'ai trouvés en lisant les sources, et qui en disent long sur l'état de l'open source en 2026.

Le premier est dans le README : à cause du spam de contributions générées par LLM, les pull requests ont été temporairement désactivées pour tout le monde sauf les collaborateurs existants. La formulation est sans ambiguïté sur le fait que les contributions LLM ne sont pas les bienvenues.

Le second est dans la FAQ : si vous n'avez pas le temps de survoler la documentation et que vous comptez vous reposer uniquement sur un outil d'IA, alors n'utilisez pas PocketBase.

Un mainteneur unique qui écrit noir sur blanc "n'utilisez pas mon projet si vous ne le comprenez pas".

Et c'est compréhensible...

Une personne seule ne peut pas absorber le volume de tickets généré par des utilisateurs qui ont vibe-codé une intégration sans jamais lire une page de doc. Le "non" en amont, c'est ce qui permet au projet de tenir 18 issues ouvertes avec 60 000 étoiles au compteur.

Comparez avec les repos populaires où le tracker est un cimetière de 3 000 tickets. La sélectivité n'est pas un défaut de communauté, c'est une condition de survie pour un projet solo.

SQLite en production, ça tient ?

C'est la première objection que j'entends à chaque fois. Et elle mérite une réponse honnête plutôt qu'un slogan.

Le chiffre mis en avant par le projet : plus de 10 000 connexions temps réel persistantes sur un VPS Hetzner CAX11 à environ 4$ par mois (2 vCPU, 4 Go de RAM). Il existe aussi un repo de benchmarks officiel pour les opérations de lecture et d'écriture.

Précision importante : ces chiffres sont auto-rapportés par le mainteneur. Ce ne sont pas des mesures indépendantes. Je les relaie comme des ordres de grandeur, pas comme une garantie contractuelle. Je n'ai pas fait tourner de charge sérieuse dessus moi-même, et tant que je ne l'ai pas fait je ne vais pas prétendre le contraire.

Ce qui est structurellement vrai, en revanche :

• SQLite en mode WAL est excellent en lecture, c'est le cas d'usage majoritaire d'une API applicative
• l'écriture reste sérialisée, donc un workload à forte concurrence d'écriture est le mauvais profil
• il n'y a pas de réplication native, le projet renvoie vers Litestream pour la reprise après sinistre
• il n'y a pas de scaling horizontal, donc votre plafond est la plus grosse machine que vous acceptez de payer

En 2026, la plus grosse machine que vous acceptez de payer, c'est un serveur dédié à 100 € par mois avec 128 Go de RAM et du NVMe. Ça couvre une quantité d'applications SaaS bien plus large que ce que les gens imaginent.

Le vrai calcul, ce n'est pas 25$ contre 4$

C'est là que ça rejoint une idée que je répète souvent sur ce blog: le prix affiché d'une brique n'est jamais le prix de votre application. Ce qui compte, c'est le coût complet d'un usage réel.

Supabase, la référence de comparaison, affiche un plan Pro à 25$ par mois. Sauf que ce montant est un plancher, pas un plafond. Le compute est facturé séparément par projet, l'egress est facturé au Go, les utilisateurs actifs au-delà du quota sont facturés en plus. Plusieurs analyses de facturation publiées ces derniers mois montrent que sur une application en croissance, le plan de base représente une fraction minoritaire de la note finale, le reste venant du compute et des dépassements.

Ce n'est pas une critique de Supabase, qui reste un excellent produit et qui est self-hostable. C'est une remarque sur la structure de coût.

PocketBase a une structure de coût différente, plate. Vous payez un VPS. Le VPS coûte la même chose que vous serviez 10 utilisateurs ou 10 000. Le jour où vous saturez, vous voyez arriver le mur, vous prenez une machine plus grosse, et vous connaissez le prix à l'avance.

C'est exactement la même logique que le coût par tâche face au prix au token sur les modèles d'IA : le prix unitaire affiché ne vous dit rien tant que vous ne savez pas combien d'unités votre usage réel consomme.

Alors, un mainteneur unique, c'est disqualifiant ?

Les chiffres sont sans appel. Sur le dépôt GitHub, le mainteneur totalise environ 2 375 commits. Le deuxième contributeur en compte 5.

Bus factor de 1. C'est l'argument massue de tous ceux qui déconseillent le projet.

Sauf que je pense que cet argument est mal posé, et je vais assumer le contraire. Un projet maintenu par une personne seule est parfois moins risqué qu'un backend financé par du capital-risque. Je m'explique.

Sur PocketBase, le pire scénario est le suivant : Gani arrête demain. Que se passe-t-il ?

Votre binaire continue de tourner. Votre fichier SQLite est toujours lisible avec n'importe quel client SQLite.

Le code est en MIT, en Go, compilable par vous. Votre application ne s'arrête pas. Vous avez juste perdu les futures mises à jour, et vous avez le temps de planifier une migration sur vos propres délais.

Sur un BaaS managé, le pire scénario n'est pas l'arrêt du produit. C'est un changement de grille tarifaire, un changement de licence, ou un rachat. Et là vous n'avez ni le binaire, ni le délai, ni le choix. Vous avez une date butoir et une facture.

Le risque n'est pas de la même nature. D'un côté un risque de maintenance, absorbable. De l'autre un risque de dépendance commerciale, subi.

C'est la même logique que je défends pour l'inférence auto-hébergée : ce qui vous protège, ce n'est pas la taille de l'éditeur, c'est le fait que l'artefact tourne chez vous et que vous ayez le droit de le recompiler.

Quand je ne le choisirais pas

Je ne vais pas vendre PocketBase comme une réponse universelle, parce qu'il ne l'est pas.

Je passe mon tour si :

• l'application a besoin de multi-région, de failover automatique ou de vrai horizontal scaling
• le workload est dominé par de l'écriture concurrente lourde
• il faut du Postgres pour de vraies raisons (extensions, pgvector, requêtes analytiques complexes)
• le client exige un SLA contractuel
• personne dans l'équipe n'a envie d'assumer l'uptime, les backups et les mises à jour

Et il y a le point le plus important, que la documentation officielle assume elle-même : PocketBase n'est pas recommandé pour des applications critiques tant que la v1.0 n'est pas atteinte, sauf si vous acceptez de lire le changelog et d'appliquer des étapes de migration manuelles de temps en temps.

4 ans après le premier commit, on en est à la v0.39. Ce n'est pas un abandon, les releases sortent à un rythme soutenu (plusieurs par mois, avec en parallèle une branche 0.22 encore maintenue). Mais le contrat est clair : la compatibilité ascendante n'est pas garantie avant la v1.

Donc c'est un choix conscient, pas un choix par défaut. Vous échangez de la garantie contractuelle contre de la simplicité opérationnelle et de la portabilité.

Pour un side project, un MVP, un intranet, un backend d'app mobile, un outil interne, une API de produit early stage : c'est difficile à battre.

Pour ma part, c'est exactement le genre d'outil que je regarde en priorité quand je monte quelque chose seul. Un artefact que je peux poser sur une machine, sauvegarder avec un cp, et déplacer chez un autre hébergeur en une après-midi. C'est la même raison pour laquelle je fais tourner Light-Whisper en local plutôt que d'utiliser une solution propriétaire.

La question que je me pose vraiment

Il y a un truc qui me travaille depuis que j'ai lu la FAQ de ce projet.

PocketBase a 60 000 étoiles en refusant l'hébergement, les dons, les PR, les ETA et les contributions IA. Pendant ce temps, on nous explique que le modèle viable de l'open source moderne, c'est la boîte financée avec une offre cloud et un plan enterprise.

Alors est-ce qu'un projet qui dit non à tout est une exception folklorique, ou est-ce que c'est justement la seule forme d'open source qui a une chance de tenir 20 ans ?

Je n'ai pas de réponse tranchée. J'ai juste remarqué que les projets qui m'ont le moins déçu sur la durée sont ceux qui ne m'ont jamais rien promis.