So I think Grist is great. The problem is that companies (including my own), already have data stored in other databases, like postgres, and it’s a ton work to migrate. Plus grist is missing some features that are critical for data (i.e. unique constraints etc.). What I’m considering doing is to use Grist as the interface to interact with the postgres data, as Grist has an amazing frontend for data entry/manipulation. The question, of course, is how to keep all the data in synch, as the postgres data would be the “source of truth.” We can do this via webhooks, but this gets very complicated quickly. Is there any way you can create some sort of connector from postgres, so that Grist gets the data from postgres and feeds it into the correct documents etc. in Grist? Does this make any sense? Have you considered this? In that way, postgres still is the source of truth, while Grist is the frontend to the database really, and Grist also stores a real-time copy of the postgres database in the grist sqlite database.
It does make sense to me. I do love GRIST as an interface to multiple related tables. Despite you can find apps that help to interact with databases, such as nocodb.com, GRIST goes beyond that, offering a more polished interface, associated with the power of Python formulas.
To have GRIST working as nocode.com, as an interface to SQL databases “on-premises”, is a dream to me! I think that would be better than “sync” features.