grist-core: a relational spreadsheet you can self-host

What grist-core is, and who it is for

Grist is described in its README as a modern relational spreadsheet that combines the flexibility of a spreadsheet with the robustness of a database. The repository gristlabs/grist-core is the community edition, the server component for hosting spreadsheets. Two sibling repositories cover other shapes of the same product: grist-desktop is a Linux, macOS and Windows app for viewing and editing spreadsheets stored locally, and grist-static is a fully in-browser build for displaying spreadsheets on a website without back-end support.

The intended user is someone who has outgrown a plain spreadsheet but does not want to hand-write a schema and a CRUD application. In Grist, columns are named and hold one kind of data, as in a database, and columns can be filled by formula with automatic updates when referenced cells change. That combination is the whole pitch. It also explains the friction: the README says this difference can confuse people coming directly from Excel or Google Sheets, and points to a separate article for spreadsheet users. If your work is mostly free-form cells, merged headers and ad hoc formatting, this model will feel restrictive rather than helpful.

The project is developed by Grist Labs, with contributions from the French government organizations ANCT Données et Territoires and DINUM. That matters for procurement in the public sector, where a codebase with government contributors is easier to justify than an unknown vendor. The last push to the repository was on 2026-09-21, and the most recent release listed is v1.7.19 on 2026-09-06.

Typed columns, Python formulas and a SQLite file underneath

Three mechanisms define how grist-core actually works, and they are worth separating.

First, the data model. Columns are typed and named. Choice and choice-list columns give records colored tags. Reference columns and reference-list columns cross-reference records in other tables, and two-way references synchronize automatically between the two sides. Attachments, dates, toggles and special numerics such as currency each get a dedicated editor. Conditional formatting lets formulas control cell styling.

Second, the formula layer. Full Python syntax is supported, including the standard library, and many Excel functions are also available. There is a formula timer for diagnosing slow formulas, and an AI Formula Assistant tuned for formula generation that the README says works with OpenAI, Llama, and other models via OpenRouter or any OpenAI-compatible endpoint. Note what that implies for self-hosting: the assistant is an integration with an external model endpoint, not something the server does on its own.

Third, storage. Documents are based on SQLite, described in the README as the most widely deployed database engine. Any tool that can read SQLite can read numeric and text data from a Grist file, which makes backups and host migration straightforward. The caveat is stated by the project itself: SQLite readers get numeric and text data, not the full document semantics. Formulas, references and widget layout live in the file but are not what a generic SQLite browser will show you.

Around the data model sit views: charts, card views, a calendar widget, summary tables for summing and counting across groups, and widget linking. The README describes this as a deliberate alternative to cramming mixed material into a table. There is also a filter bar, widget duplication, and a compare-documents feature for seeing what changed between two copies.

Installing grist-core with Docker

The README points at Docker as one of the ways to see exactly what is present in grist-core, and the repository ships a Dockerfile and a docker-compose-examples directory. The Dockerfile is a multi-stage build: a Node 22 stage installs production dependencies with yarn, a builder stage adds devDependencies to compile the TypeScript, and extra node dependencies can be injected through a build context named ext. The build sets GRIST_SKIP_EXT_AUTOSETUP=1 so the postinstall extension hook does not run during the image build.

Because the repository includes docker-compose-examples rather than a single canonical compose file, start from the example that matches your setup instead of inventing one. The Dockerfile also documents how to build with an extension context:

docker buildx build -t ... --build-context=ext=<path> .

That command comes from the comment block at the top of the Dockerfile. The code in the path supplied as ext is built along with the rest of Grist. If you would rather build from source, the package.json exposes the relevant scripts:

yarn install
yarn run build

The install runs a postinstall script, buildtools/install_edition.sh, which is how the edition selection is applied. Two scripts switch editions explicitly: yarn run set-community-edition writes community to a grist-edition file and reinstalls, and yarn run set-full-edition writes full. The default in this repository is the community edition, so you only need those scripts if you are deliberately changing the target.

Running from source and the edition trap

For development, the start script is sandbox/watch.sh, with start:debug and start:debug-brk variants that pass NODE_INSPECT flags. There is also an install:python script, buildtools/prepare_python.sh, which tells you something important about the runtime: Python is a separate preparation step, not a transitive dependency yarn will pull in for you. Since formulas are Python, a missing or mismatched Python environment is the failure mode you will hit first, and it will look like broken formulas rather than a broken install.

Production builds use build:prod and then start:prod, which runs sandbox/run.sh. The test suite is invoked through test/test_env.sh with Mocha across common, client, nbrowser, server and gen-server suites, and the package.json includes dedicated browser test scripts with headless and logging environment variables. That is a large surface to keep green if you fork.

The edition trap deserves its own paragraph. The README links to a section titled features not in grist-core, and the repository has scripts that switch the installed edition between community and full. Grist Labs sells an edition with additional features, and offers free and paid hosted services plus cloud packaging. So the honest framing is this: grist-core is a real server with a real feature set, but it is explicitly a subset. Before you plan a deployment, read that list. Discovering that a feature you assumed was core is enterprise-only, after you have migrated data, is the expensive version of this mistake.

Where grist-core is the wrong tool

The clearest mismatch is the spreadsheet refugee. If your workflow depends on arbitrary cell placement, merged cells as layout, or dozens of loosely structured tabs maintained by different people, the typed-column model will fight you. The README acknowledges the confusion directly and links to a getting-oriented article, which is a reasonable thing for a project to do but does not remove the learning cost.

The second limitation is operational. This is a self-hosted Node application with a Python dependency for formulas. The README does not document rollback, and it does not describe a migration path between versions. Releases are frequent (v1.7.17 in July, v1.7.18 in August, v1.7.19 in September 2026), so an upgrade cadence exists, but the upgrade procedure itself is not spelled out in the README. Plan to test upgrades against a copy of a document before touching production.

The third is the AI Formula Assistant. It is an outbound integration to OpenAI, Llama via OpenRouter, or another OpenAI-compatible endpoint. In an air-gapped or privacy-constrained deployment, that feature is either unavailable or a policy problem, and the README does not present a local-only alternative.

Finally, the static and desktop variants exist precisely because the server is not always the right shape. If you only need to display a spreadsheet on a website, grist-static avoids the back end entirely. If you need local editing, grist-desktop is the intended answer. Running grist-core for either of those jobs adds an operational burden you do not need.

grist-core against Airtable and plain SQLite

The README itself invites the Airtable comparison and links to a dedicated article. The practical difference is where the data lives and who operates it. Airtable is a hosted service: you get the base, the API and the automations without running anything, and you accept vendor hosting. grist-core is the opposite trade. You run the server, you own the SQLite files, and you can read numeric and text data out of them with any SQLite tool. The data model is familiar if you come from Airtable, which the README states outright.

The second alternative is not a spreadsheet product at all: a plain SQLite database plus a small application. Grist's document format is SQLite underneath, so the storage layer is comparable. What you would be giving up is everything above it, the formula engine with Python and Excel functions, references and two-way references, forms, dashboards, the REST API with its interactive console, and the incremental import path that lets you load three months of bank activity and later add a new month without duplication. Building that yourself is a real project, not a weekend.

A third comparison sits inside the same repository family: grist-desktop and grist-static. They are not competitors so much as different deployment targets for the same document format, which is the strongest argument for the format itself. If your choice between them is unclear, the deciding question is whether the spreadsheet needs to be shared and concurrently edited (server), displayed read-only (static), or edited locally (desktop).

Licence, maintenance and upgrade cost

grist-core is Apache-2.0, and the README states that grist-core, grist-desktop and grist-static are all under that licence. Apache-2.0 is permissive and includes a patent grant, which is generally the reason organizations accept it without a legal review cycle. The repository also carries a NOTICE.txt file, which Apache-2.0 requires you to preserve in redistributions. This is a description of the licence text, not legal advice; if you are embedding Grist in a product, have counsel read the NOTICE and the enterprise feature boundary.

The commercial structure is worth stating plainly. Grist Labs sells an edition with additional features and offers hosted services. Nothing about the community edition is a trial, but the feature list is deliberately partitioned, and the edition scripts in package.json exist because the same codebase serves both targets. If you build from source, be aware that the postinstall hook reads the edition file, so a stray grist-edition file changes what you install.

Maintenance cost splits into two parts. Upstream moves quickly: three releases between late July and early September 2026, and the repository was last pushed on 2026-09-21. Keeping pace means tracking releases and re-testing your documents. Your own cost is the Python environment for formulas, the persistence volume for documents, and whatever reverse proxy and backup tooling you put in front of it. The README does not document rollback, so the backup you export is your rollback, which is exactly why the project emphasizes backups you can confidently restore in full.

Editorial conclusion

Adopt grist-core if your data has a stable schema, your team writes formulas rather than free-form cells, and you are willing to run a Node server with Python available for formula evaluation. Do not adopt it if you need the features the README lists as absent from grist-core, if you expect Excel muscle memory to transfer without friction, or if you cannot operate a self-hosted service. Before committing, verify three things: that the features you rely on are not on the enterprise-only list, that a document you export restores in full, and that your Python environment is prepared with the install:python script so formulas evaluate correctly.

Frequently asked questions

Official sources

1. gristlabs/grist-core on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases