Grist as database backend (Headless CMS alternatives)

Grist Feedback
#1

Hello, thank you for Grist!
Today in search of a replacement for Nocodb, I found your product, at first glance it looks like an order of magnitude usability.
Why NocoDB?
Main: manage and develop MY MariaDB like as Excel like as Airtable.
Easy docker install on my Synology NAS, easest connect to DB and excel like phpmyadmin. Column = Database field we have Excel like Headless CMS for our database.

First impressions from studying the Grist documentation are a delight. Widgets like dashboards are exactly what NocoDB, Airtable, Baserow lack. Conceptually, your product is similar to desktop GS-base but more promising.

But delving into the study of the Grist community, I realized that just like GS-base (closed DB) or Baserow (PostgreSQL) we are limited to one database for data is sqlite.

Why not Airtable or Grist Cloud?
It’s simple, according to the law of my country, I am obliged to keep the server on which the personal data of users in this country is stored.

I want to ask the Grist:

  1. I want to support Grist but I can’t use Grist Cloud, have you thought about charging for example a self-hosted setup with white label option and connection to MySQL or MariaDB for metadata and datastorage?
2 Likes
#2

Hi @BiBo, thanks for posting and the kind words. You likely know, but just to confirm, you can self-host Grist using https://github.com/gristlabs/grist-core/.

Yes for most within-document storage we just support SQLite. For storage of other information, we use PostgreSQL, and it wouldn’t take a huge amount of work to support MySQL/MariaDB. But for document storage, that would be another level of work. There’s a brief description of the changes needed at https://github.com/gristlabs/grist-core/issues/87#issuecomment-959102695.

For our hosted service, working with SQLite brings a lot of simplicity, and for our users it works well as a portable, downloadable document format, so I don’t see us building out support for other database back-ends in the immediate future. You’re not the only one to ask for this though.

1 Like
#3

Thank you.
Any Environment variables available for docker setup?
How to set up multi-user access via SSO without editing the code, using Environment variables bcs if update container from hub we loose this data. The idea was the same as Configure SSO on Synology.

#4

There’s a list of environment variables at https://github.com/gristlabs/grist-core/#environment-variables. Self-hosted Grist should work with anything that supports SAML, including Auth0 and Authentik. You can see one person’s adventure in getting Authentik set up here: https://github.com/gristlabs/grist-core/issues/135. We’ve had a burst of people trying self-hosting this week, and the knowledge for how to do it is a bit fragmented, we’ll be working on consolidating all that.

1 Like
#5

Does grist-core also inherit the limit at ~100k records or is that coming from the dependencies of the hosted version?

#6

That number is based on experience with Grist running with the CPU and memory resources we give it in our hosted service. If you have far more records, Grist as it is today won’t be a super experience (we have ambitions to iterate on that of course). The main architectural constraint currently is the spreadsheet side of Grist (tracking dependencies between cells etc).
When self-hosting, you can scale CPU and memory, so if things start getting sluggish you have options.

#7

Thanks - useful to know :slight_smile:
Can you share what CPU and memory is dedicated to the hosted instances?