DrystoneCMS

Drystone CMS vs. Sanity
Schema as code, without the cloud.

Sanity got a lot right: content is structured data, schemas belong in code, and preview should be real-time. But that content lives in their Content Lake, and that is precisely the part you cannot move.

Get started See the comparison

The short version

Of every CMS on this list, Sanity is philosophically the closest to Drystone: schema as code, structured content, excellent preview. The difference is where your data sits and what you pay when it takes off. Drystone keeps the same ideas on your own server, with standard REST instead of a bespoke query language, and no bill that grows with success.

Point by point

Drystone CMS next to Sanity.

CriterionDrystone CMSSanity
Where content lives Drystone CMSYour SQLite file, on your disk. SanityTheir Content Lake. The data layer cannot be self-hosted.
Schema Drystone CMSschema.yaml in git, plus a visual builder that edits the same file. SanitySchemas in JavaScript, in git — Sanity does this very well.
Querying Drystone CMSREST with filtering, sorting, field selection and ?populate=, plus an OpenAPI spec. SanityGROQ: powerful, and a language your team has to learn separately.
Editor Drystone CMSBlock editor with autosave, drafts, scheduled publishing and split-screen preview. SanitySanity Studio, customisable in React, with strong real-time collaboration.
Price Drystone CMSFree; you pay for your own server. SanityA free tier, then per user, API request and bandwidth.
Lock-in Drystone CMSNone. Export to JSON or Markdown with one command. SanityDataset export exists, but GROQ, portable text and Studio do not move with you.
Real-time Drystone CMSNot in v1: autosave and token-based preview, no live collaboration. SanityReal-time multiplayer editing, and it is good at it.
Install Drystone CMSOne binary, under a minute. SanitySet up and deploy Studio; the back end is their service.

What Sanity does well

  • Structured content as the starting point rather than an add-on — that saves rework later.
  • Schemas in code and in version control, with a Studio you can customise in React.
  • High-quality real-time collaboration and live preview.
  • GROQ is a powerful query language once your team knows it.

Where it hurts in practice

  • Content lives in their cloud; the data layer is not self-hostable.
  • Usage-based pricing is hard to predict as you grow.
  • GROQ and portable text are proprietary standards that do not travel with you.
  • You depend on their availability, including for your own editorial work.

Honest advice

When you are better off staying with Sanity.

Stay with Sanity if…

Choose Sanity if real-time collaboration with several editors in the same document matters, if you want to customise Studio heavily, or if you deliberately do not want to run infrastructure. On those points Sanity is simply better than Drystone.

Choose Drystone if…

Choose Drystone if you want the same structured-content approach with your data on your own server, a REST API your team already knows, and no bill that scales with success.

Switching

From Sanity to Drystone, in four steps.

  1. Translate your Sanity schemas into schema.yaml; most field types map directly.
  2. Export your dataset (sanity dataset export) and import the documents and assets.
  3. Replace GROQ queries with REST calls — filtering and field selection cover most of them.
  4. Convert portable text into the editor's block structure; usually a single script.

Install it now

Frequently asked

What people ask before switching.

Does Drystone have real-time collaboration?

No, not in v1. There is autosave, drafts, scheduled publishing and split-screen preview. Two people in the same document at once is not what this CMS does; if that is part of how you work, Sanity is the better choice.

Is there an equivalent of GROQ?

Deliberately not. There is standard REST with filtering, sorting, field selection and relations via ?populate=, documented in an auto-generated OpenAPI 3 spec. Less powerful at the extremes, and nothing new to learn.

Can I bring my portable text along?

Yes, with a conversion step. Portable text is structured JSON and the block editor also works in blocks, so the mapping is scriptable. Custom block types you defined yourself need their own mapping.

Other comparisons

Drystone vs. WordPress Drystone vs. Strapi Drystone vs. Contentful Drystone vs. Directus Drystone vs. Payload Drystone vs. Ghost Drystone vs. PocketBase