DrystoneCMS

Drystone CMS vs. PocketBase
Same binary promise, different user.

PocketBase showed how far one binary with SQLite inside gets you, and that idea is shamelessly borrowed here. The difference is who it serves: PocketBase serves the developer, Drystone also serves the editor.

Get started See the comparison

The short version

Building an app that needs auth, real-time and a datastore? PocketBase is exactly right. Need someone other than you to put content in? Then everything that goes with that is missing: drafts, version history, preview, a block editor, and a schema that lives in git. Drystone is the same technical choice, made for content instead of application data.

Point by point

Drystone CMS next to PocketBase.

CriterionDrystone CMSPocketBase
Distribution Drystone CMSOne binary with the admin built in — we agree here. PocketBaseOne binary with the admin built in.
Database Drystone CMSSQLite in WAL mode; backup is one file. PocketBaseSQLite in WAL mode; backup is one file.
Audience Drystone CMSDevelopers and editors, explicitly both. PocketBaseDevelopers. The admin is a database manager.
Editor Drystone CMSBlock editor with autosave, drafts, scheduled publishing and split-screen preview. PocketBaseForm fields with a rich-text field; no editorial flow.
Versions Drystone CMSVersion history per document, with a diff and one-click restore. PocketBaseNot available.
Draft & publish Drystone CMSDraft ↔ published, scheduled publishing, token-based preview. PocketBaseBuild it yourself with a status field and API rules.
Schema Drystone CMSschema.yaml in git; the visual builder writes that same file. PocketBaseThrough the admin UI; migration files are a separate step.
End-user auth Drystone CMSNot available; auth here is for the editorial team, not your app's users. PocketBaseFull user authentication including OAuth — a genuine strength.
Real-time Drystone CMSNot available; webhooks on publish and change. PocketBaseReal-time subscriptions built in.

What PocketBase does well

  • One binary with SQLite and an admin inside — small, fast and easy to deploy.
  • Full user authentication with OAuth, ready for your app.
  • Real-time subscriptions without extra infrastructure.
  • Extensible with JavaScript hooks or as a Go framework.

Where it hurts in practice

  • No editorial experience: no drafts, no versions, no preview, no block editor.
  • The schema lives in the admin UI rather than in version control.
  • Media is file storage; no image transformation or alt-text policy.
  • A non-technical editor is effectively handed a database form.

Honest advice

When you are better off staying with PocketBase.

Stay with PocketBase if…

Choose PocketBase if you need an application back end: end users signing in, real-time data, and you as the only person entering content. Nothing gets you there faster.

Choose Drystone if…

Choose Drystone once editors get involved, or the moment drafts, version history, preview and a schema in git start to matter to you.

Switching

From PocketBase to Drystone, in four steps.

  1. Move your PocketBase collections into schema.yaml — the field types largely correspond.
  2. Export your records as JSON through the API and import them with the import CLI.
  3. Copy the files from pb_data/storage into the media folder.
  4. Feel free to keep PocketBase for your app's auth: the two do not conflict.

Install it now

Frequently asked

What people ask before switching.

Can Drystone handle authentication for my app?

No. Auth in Drystone is for the editorial team: roles, sessions, TOTP two-factor and API keys with scopes. Signing in your application's end users is a different problem — PocketBase or an auth service is the right place for it.

Why not just PocketBase with a custom admin?

You can, and that is exactly the project Drystone saves you: drafts, versions, preview, scheduled publishing and a block editor are months of work together — and then you maintain your own admin next to your product.

Is there real-time?

Not in v1. There are webhooks on publish, change and delete, which is the usual pattern for static rebuilds and integrations. If you need live updates in the browser, PocketBase is stronger there.