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.
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:
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?
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.
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.
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.