Sanity's Internal Tech Stack: GROQ Language, Datastore, and Infrastructure

8 replies
Last updated: Sep 22, 2020
I wonder if any Sanity insiders would share some description of their internal tech stack. What language is the GROQ DSL written in, and what were the influences / design decisions in developing it? Are the datastores document db's, or using JSON fields in PostgreSQL? Is the infrastructure on a cloud provider? And anything been written comparing Sanity to Prisma Server and Hasura?
AI Update

Great question! While Sanity doesn't publish exhaustive details about every internal implementation choice, there's actually some solid information available about their tech stack from a community discussion thread and a blog post about open sourcing GROQ.

Tech Stack Overview

Query Engine & Language:

  • The GROQ query engine is written primarily in Go, which makes sense for performance-critical query processing
  • Many of Sanity's services are built with JavaScript/TypeScript
  • GROQ (Graph-Relational Object Queries) development started in 2015, led by Simen Svale Skogsrud and Alexander Staubo, with Erik Grinaker contributing work on consistency
  • Magnus Holm built Glush, a "parser-parser" that generates GROQ parsers for different languages (including JavaScript)

Data Storage:

  • Uses both PostgreSQL and Elasticsearch for storage
  • This dual-database approach likely leverages Postgres for transactional data and Elasticsearch for search/query capabilities

Infrastructure:

  • Runs on Google Cloud Platform
  • Uses Kubernetes (K8s) for orchestration
  • Leverages Google's CDN for content delivery

The GROQ specification was open-sourced in 2019, and there's also a CLI tool you can use to experiment with GROQ queries against JSON data.

GROQ Design Influences

GROQ was designed specifically for querying JSON documents with a focus on:

  • Human readability and expressiveness
  • Filtering, projection, and joining capabilities
  • Graph-relational traversal (hence the name)
  • Working naturally with nested/hierarchical content structures

The precursor to Sanity was a project called Pebbles, which influenced some of the design decisions.

Sanity vs Prisma/Hasura

Regarding comparisons to Prisma Server and Hasura - I couldn't find official comparison content from Sanity on this. However, the key architectural difference is:

  • Hasura/Prisma are primarily GraphQL layers over existing databases, auto-generating APIs from your database schema
  • Sanity is a complete content platform with its own storage layer, query language (GROQ), real-time capabilities, and content-specific features like the Studio editor

Sanity is purpose-built for content operations, whereas Hasura/Prisma are more general-purpose database API layers. They solve different problems - Sanity competes more directly with headless CMS platforms like Contentful or Strapi, while Hasura/Prisma are tools for building APIs on top of your own database.

The choice between them really depends on whether you need a managed content platform (Sanity) or want to build your own data layer with GraphQL tooling (Hasura/Prisma).

Show original thread
8 replies
There might be an opportunity coming up soon where you get some answers. Stay tuned 🙂
Meanwhile, there are some details to be had here:
https://gcppodcast.com/post/episode-232-sanity.io-with-simen-svale-skogsrud-and-knut-melvaer/
Thanks Knut!
But shortly: Query engine is written in mostly Go, a lot of the services in JS/TS, we use Postgres/Elastic, it runs on
 google cloud using K8Ss and their CDN.
That makes a lot of sense, especially Elastic 😀 I was guessing the query engine might be in Ruby :ruby:
The Sanity precursor was: https://bengler.no/pebbles 🙂
And you could, at least theoretically, make a parser in Ruby as well:
https://www.sanity.io/blog/why-we-wrote-yet-another-parser-compiler#glush-the-project-6541c09fa22b
That's a great link, thanks. That's a really awesome library - didn't have any idea about it. Hope it stays maintained - I see last code commit on Glush is over a year ago. I've never used a scannerless parser generator before - but Glush creates Javascript parsers, which is incredibly useful!
Yeah – we have been busy on other things (including scaling the backend), but I think there will be more happening
Thanks again for the info. I'm reading through the sanity docs in detail and planning a test project. I've had studio and a gatsby front-end set up for a bit and an account, now to dig through and figure it out.

Sanity – Build the way you think, not the way your CMS thinks

Sanity is the developer-first content operating system that gives you complete control. Schema-as-code, GROQ queries, and real-time APIs mean no more workarounds or waiting for deployments. Free to start, scale as you grow.

Was this answer helpful?