PocketBase

PocketBase とは実際のところ何か

たいていのバックエンドは組み立て作業だ。どこかにデータベース、その隣に認証サービス、アップロード用のオブジェクトストレージ、いつか作ろうと思っている小さな管理画面、そしてそれらをつなぐ接着剤。PocketBase はこれを1つのプロセスとディスク上の1ファイルにまとめる。自分のプラットフォーム向けの実行ファイルを落とし、起動し、ブラウザでダッシュボードを開き、コレクションを定義すれば、その時点でアプリには API がある。コンテナのオーケストレーションもマネージドデータベースも別立ての認証ベンダーも要らず、最初のリクエストが通るまでに設定すべきものは何もない

引き換えになるものは、はっきりしていて意図的でもある。データベースがネットワーク越しではなく組み込みであるため、バックエンド全体が SQLite ファイル1つを抱えた1プロセスになる。それが運用をここまで単純にしている理由であり、同時に水平スケールが他の構成とは別の議論になる理由でもある。このページを読む多くの人がいる段階、つまりまだ利用者のいないアプリや数百人規模のアプリにとって、この取引は明確に有利で、しかも思っているよりずっと長くその状態が続く

• リアルタイム購読つきの組み込みデータベース バイナリの中に SQLite があり、加えて購読 API があるので、クライアントはポーリングせずに変更を受け取れる。自動更新される UI が、プロジェクトではなく初期状態になる
• ユーザーとファイルが最初から入っている 認証とユーザー管理が同梱されており、ファイルの取り扱いも同様だ。初日に外部サービスを呼び込みがちな二つの機能が、すでにそこにある
• 管理ダッシュボードと REST 風の API コレクションを定義し、レコードを編集し、データを確認するための Web UI があり、その下に公式 SDK が包む HTTP API がある。JavaScript SDK はブラウザ、Node.js、React Native をカバーし、Flutter とデスクトップ向けには Dart SDK がある
• 可搬な実行ファイル1つ 配布されるバイナリは純 Go の SQLite ドライバを使い、CGO を無効にしてビルドされるため、公開されている Linux、macOS、Windows、FreeBSD、OpenBSD、NetBSD 向けの一覧にクロスコンパイルできる。デプロイはファイルを1つ置いて実行するだけだ

動かし方は二通りあり、その選択は後から効いてくる

一つ目は単体アプリとして動かす方法だ。自分のプラットフォーム向けのリリースを落とし、展開し、serve コマンドを実行すればそれで終わる。配布バイナリには JavaScript の VM も入っているので、Go に触れることも再ビルドすることもなく、フックや独自エンドポイントを JavaScript で追加できる。今日の午後のうちに誰かの前に試作を出せるのはこの道で、ここに留まり続けるのもまったく妥当な判断だ

二つ目は Go のライブラリとして使う方法だ。自分の Go プログラムに PocketBase を取り込み、そのライフサイクルイベントに対してルートと業務ロジックを登録し、結果を、つまり自分のコードとバックエンド全体を、静的リンクされた1つの実行ファイルにコンパイルする。README にある最小例は十五行ほどだ。これを初日に知っておくべき理由は、これが避難口だからだ。ロジックが設定の範囲を超えたときに単体アプリが行き止まりにならないのは、同じプロジェクトがその下のフレームワークでもあるからだ。必要条件は控えめで、ビルドには現在 Go 1.27 以降が要る

創業者のグロース基盤のどこに収まるか

PocketBase はビルドのための道具であってグロースの道具ではないので、グロースへの貢献は間接的であり、そこは正直に言葉にしておきたい。着想を得てから、見知らぬ人がログインできる何かができるまでの数週間を消してくれる。それが重要なのは、需要について学べることのほとんどが、その地点を越えるまで手に入らないからだ。一方でこれは、作ったものに誰かを連れてきてはくれない

• 最初に動くバージョンのために 認証とストレージとデータベースがダウンロード1つで揃うのは、試作から、本物のログインを前に置ける何かへの、いちばん短く正直な道だ。フロントを AI ツールで作っているなら、ビルドが終わったところから先はバイブコーディングで作ったアプリを広める一番いい方法は何かが引き受ける
• お金を払いたくない社内ツールのために 順番待ちリスト、コンテンツカレンダー、アプローチ管理、最初の五十件の会話のための軽い CRM。コレクションと管理 UI だけで、維持する製品にならずに驚くほど広い範囲を賄える
• グロースの層の代わりではなく、その隣に ここにあるものは、ポジショニングを書くことも、何かを公開することも、顧客に返事をすることもない。製品ができた瞬間に仕事の形はまるごと変わる。次の問題は最初の100人のユーザーをどう獲得するかであり、そちらの方が難しい
• 何を採用しようとしているのかを把握する ライセンスは MIT で、README はその上に作ったサービスを販売することを含め、商用利用を明示的に認めている。同時に 1.0 以前であり互換性を壊す変更が想定されているうえ、質の低い自動生成の投稿が相次いだため、リポジトリはプルリクエストを既存の協力者に一時的に限定している。パッチではなく issue を出すつもりでいた方がいい

SQLite を本番で運用して学んだこと

ここで私たちは中立ではなく、そこが役に立つ部分でもある。AgentCeres も本番で SQLite を使っているので、以下は外からの論評ではなく、自分たちが下した判断の話だ。単一ファイルのバックエンドが変える最大のことは、そのファイルがどこに置かれているかが設計そのものになる点だ。私たちのファイルはマウントしたボリュームの上にあり、繰り返し出会った失敗は、コンテナが書いたもののうち誰も永続ストレージへ送っていなかったものが、次のデプロイを単に生き延びないというものだった。しかもそれはエラーとして名乗り出ない。何かを静かに忘れてしまったアプリとして現れる。データ喪失の届き方としては最悪の形だ

二つ目の驚きは、希少な資源がディスク容量ではなくボリュームそのものだったことだ。私たちのホスティング事業者はプロジェクトあたりのボリューム数に上限を設けており、どの容量制限よりもはるかに早くその天井に当たった。結果として再設計を迫られ、コンテナは使い捨てになり、永続的な状態はそれらより長く生きるデータベースとオブジェクトストレージへ移った。1つの製品のために PocketBase を1つ動かすなら、この話が当たることはない。顧客ごとに1つずつ欲しくなっている自分に気づいたら、その前提で設計する前にボリュームの数を数えてほしい

三つ目は SQLite 固有の話で、私たちは本当に混乱した午後を一つ失った。SQLite の型付けは柔軟だ。私たちはタイムスタンプを、ある列では整数として、別の列ではテキストとして保存していた。この二つの形式をまたいだ比較はエラーを一切返さず、ただ静かに誤った行を返す。読んでいる限り正しく見えるクエリのままで。PocketBase は自前でスキーマを管理するので、同じファイルに対して自分でクエリを書き始めるか、自分の Go 拡張を書き始めるまでは、この問題からはかなり守られている。そしてその瞬間から、これは自分の問題になる。保存形式は一度決め、比較を信じる前に列の型を確認しておきたい