Achar 2.0 is out — GROQ projections, draft previews, and a schema-aware studio.
The content operating system
Achar is a content lake, a query language, and a studio: one place to model your content, one API to read it from anywhere, and a publishing flow your editors can follow without a deploy.
No credit card. A dataset, a schema and a studio in about five minutes.
Trusted by teams at
- Northwind Media
- Kestrel Health
- Lantern Financial
- Fjord Commerce
- Atlas Robotics
- Meridian Travel
The core idea
Content is data. Everything else follows from that.
A page builder stores the page. Achar stores the thing the page is about — as a document with a type, shaped by a schema your team owns. Write it once in the studio, then query it from a website, an app, a print pipeline or an agent, each asking for exactly the fields it needs.
The type definition
A schema is a TypeScript-shaped declaration, not a form builder. It is versioned with the project, it is what the studio draws its editors from, and it is what a document is validated against on the way in.
How it worksimport { defineType, defineField } from '@achar/schema'
export const post = defineType({
name: 'post',
title: 'Post',
kind: 'document',
fields: [
defineField({ name: 'title', title: 'Title', type: 'string', required: true }),
defineField({ name: 'slug', title: 'Slug', type: 'slug', required: true }),
defineField({ name: 'body', title: 'Body', type: 'portableText' }),
defineField({ name: 'author', title: 'Author', type: 'reference', to: ['author'] }),
defineField({ name: 'categories', title: 'Categories', type: 'array', of: [
defineField({ name: 'category', type: 'reference', to: ['category'] }),
] }),
],
})The rest of the platform is the consequence: a lake that holds it, a studio that authors it, and a CDN that delivers it.
The platform
Everything between a draft and a hundred channels.
Twelve pieces, one system. They are listed in the order a project grows into them — the first three are what you need on day one, and the last are what you need once there are three frontends and a migration.
Content
Model it, author it, and keep what you are working on away from what is live.
Platform
Query it, deliver it at the edge, and keep every channel reading the same source.
AI
Hand agents and models the same typed content your pages are rendered from.
The studio
A studio that draws itself from your schema
There is no page builder here and no field to drag. The schema declares what a post is, and the studio renders the editor for it — the right control for a slug, a reference picker that searches the documents it points at, a rich-text field that produces Portable Text rather than HTML. Change the schema and the studio changes with it, for everyone, immediately.
- Drafts and published rows are separate documents, so a week of editing never touches what is live.
- Publishing is a step somebody takes, with an intent, not a side effect of typing.
- Required fields are required at the write, so a document cannot be saved half-shaped.
Real-time collaboration
Several editors, one document, no locking
Presence and document updates arrive over one connection, so two people can work in the same post and see each other's typing settle as it is committed. Nobody checks a document out, nobody overwrites anybody, and the history of who changed which field is a thing you can read rather than a thing you reconstruct.
- Field-level conflict resolution, with revisions to compare against.
- Presence that says who is in the document and where they are in it.
- A review step for the person who is allowed to publish.
Delivery
Reads served from the edge, in one round trip
Every query is answered from a cache in front of the API, keyed by the query and the perspective it was asked at. A published page is bytes from the nearest edge; a preview is the draft, uncached, for exactly the person who is allowed to see it. Invalidate by tag when a document is published, and the pages that read it — and only those — are rebuilt.
- Under 50 ms at p95 for a cached query, from anywhere on the network.
- Tag-based invalidation driven by the publish webhook, not a full rebuild.
- Assets on their own distribution, transformed on request rather than at upload.
Customers
Teams who stopped maintaining four copies of the same sentence.
Every story here is a document in the dataset this page was rendered from.
We moved eleven mastheads into one lake and stopped maintaining eleven integrations. The part I did not expect is that our editors started reusing things — a chart, a glossary entry, a bio — because for the first time they could find them.
Clinical content is reviewed by people who bill by the hour, so every round trip costs real money. Publishing against a schema means the content arrives at review complete instead of arriving to be corrected.
Every disclosure on our site is a document with a review date and a named owner. Modelling that as content rather than as a page template is what finally made the audit a query instead of a spreadsheet.
- 18 msMedian cached query, from the nearest edge
- 99.99%Content delivery availability, trailing 12 months
- 4BDocuments served from Achar datasets this year
- 2,400+Teams publishing through a content lake
Integrations
The content goes where the work already happens.
Achar is a query endpoint and a webhook, so the interesting question is never whether it integrates — it is what you point at it. These are the ones teams ask about first.
Pricing
Priced by documents, not by editors.
Invite the whole company to the studio on every plan. What a plan changes is how much content you store, how much bandwidth you serve, and how much of a conversation you get to have with us about it.
- One editor and two datasets
- 1,000 documents
- GROQ queries and the HTTP API
- Asset pipeline with CDN delivery
- Community support
- Unlimited editors and datasets
- 50,000 documents
- Draft previews and revision history
- Webhooks with filters and projections
- Roles, invitations and API tokens
- Email support in one business day
- Everything in Growth
- Unlimited documents
- Audit log export
- Custom webhook projections and replay
- 99.95% uptime commitment
- Priority support with a two-hour response
Questions
The things teams ask before they move.
Everything below is a document in the dataset this page renders — the question, the answer, and the order they appear in.
- Achar is a content lake with a query language and a studio. You model your content as documents with a schema, author them in the studio, and read them from any surface with one HTTP API. The schema is shared by all three, so the studio draws its form from the same definition your queries run against.
- A page-based CMS stores the page. Achar stores the story and lets each surface decide what a story looks like, which is what makes the second frontend — an app, a partner feed, a support site — a query rather than a second copy of your content.
- You have to read one. Most reads are a filter and a projection, which is a line you can copy from the studio and adjust: the studio runs your query against the dataset as you write it, so the first draft of any query is a thing you can see working before it reaches your code.
- Yes, and the honest answer is that the modelling is the work rather than the transfer. A dataset exports and imports as portable JSON with its schema, and the migration is usually a script that maps fields, run first against a staging dataset and checked with a query before it is run again against production.
- In your own AWS account on the paid plans: DynamoDB for documents, S3 and CloudFront for media, Cognito for sign-in. You can deploy the backend with the CDK app in this repository, which means the content outlives any decision you make about us.
- Nothing stops working and nothing is deleted. The plan limits are checked when a document is written, so the editor is the first thing to tell you, and upgrading keeps every id, revision and reference exactly as they are.
- It drafts into the draft row and stops there. Suggestions are attached to a field with a schema behind it — an excerpt, a translation, a category — and a person accepts or rejects each one. Nothing reaches a published document without somebody pressing publish.
- Create a project, seed a dataset with the sample content in this repository, and query it. The whole path — schema, documents, query, published page — is about ten minutes, and there is a demo app that does nothing but call the API so you can see what a third-party client looks like.
Your content already wants to be structured.
Make a project, define a type, publish a document. The first three things you need are free, and the query you write for them is the same query you will be writing in three years.