Founder of https://plato.io here.

We support concurrent editing, so you see updates from your teammates in realtime, but we just haven't built a frontend for it yet, so you don't get the visual indicators a la Figma of where your teammates are and what they're doing.

Email me if you want to chat more: mgummelt@plato.io

hi michael, plato does look interesting, but probably won't fit my needs. i'm replying here rather than over email because the reason why brings up another interesting point - pretty much all the datagrid tools in the low/no-code space seem to be focused on the "company's internal tools" use case, where you have a few admins who need access to the raw data in the database and want a nice UI to edit it with.

what i'm trying to build is a multi-user version of a desktop app, so while i'm not really opposed to paying for a good tool (albeit at a nonprofit-friendly tier :)), per-user pricing is a non-starter, as is the high cost of self-hosting.

by way of comparison, the current "product" is a google sheet with an attached script file, and when someone wants to use it, i just send them a link to clone the sheet, and they have their own instance that they can share with whoever they like, setting read/edit permissions entirely by themselves. even if the non-google-sheets version ends up being something i need to host myself, i would like to replicate that level of ownership, where a group of users can create their own isolated instance and control its sharing and lifetime themselves.

what i'm looking for is not so much low-code, but a collaborative grid component that i can use as a primary user interface, either to drop into my app (if sufficiently modular) or build the rest of my app around (if sufficiently extensible). i am just a bit astonished that no one else, open source or otherwise, seems to have had the same need.

Or, alternatively, I want a spreadsheet that can be driven by an external program.

I finally sat down and wrote a simple terminal program to manipulate tabular data just so I could drive it from Python, Zig, Rust, etc.

At various meetups, I have discovered that quite a few of us have written a "shitty limited spreadsheet" because you can't drive the spreadsheets programatically.

in my case the killer feature is the collaborative editing, but yes, it would be great to have the spreadsheet just running in its own server and supporting web connections but also rpc calls from another process running on the same box. if grist supported that it would likely satisfy my use case completely.

This is what we're trying to do with Mathesar (https://github.com/centerofci/mathesar). We probably don't meet your needs yet because we don't support real-time concurrent editing, but we're actively working on the project and it is early days.

ooh nice, i'll star it and follow the progress with anticipation :)

I'm pretty much looking for the same thing. It's sad how most of these project try to add their own layer ("vocabulary") on top of the relational semantics without first trying to surface as much of it as possible.

What I'd like to see is something that can connect to a pg server (or sqlite, or mariadb, but I think settling on one is more feasible) and tries to surface as much as possible of the underlying data representation, and add features that are translatable to how pg works, instead of just using pg (and in grist's case, sqlite) as a dumb backend.

You've described exactly what we're doing with Mathesar: https://github.com/centerofci/mathesar

Disclaimer: I also mentioned Mathesar in a sibling comment but this describes our vision so exactly that I thought it was worth mentioning again.

Have you seen https://github.com/nocodb/nocodb? I'm not sure it supports concurrent editing, but seems like it might.

I have, and it does not. I filed an issue asking if it was on their roadmap, but they said they didn't have plans for it.