I think some of those data sets are likely too big for our poor demo server. It's had a stressful day.
I did try with some of the smaller sets, though, and they seem to work. An advantage of Mathesar is that you can always self-host, and provision enough resources for whatever data size you have!
Not at the moment, but it is in our roadmap[1]. In fact, we're planning to help users start or tinker with data explorer, then switch to an SQL editor starting from their exploration so far. That way, they can use features or queries beyond what we currently support in the GUI.
I agree that we have some work to do on access control. In fact, we have setting up Mathesar users with the 1:1 database user mapping in our roadmap[1]. Assuming you're referring to the Database super user as being a problem, we also have giving more granular control over that to the installer in the future. I completely understand reluctance to give a webapp super user access to a production database.
Very nice to hear, I will follow your project.
One of the projects I was thinking about is financial systems used by government actors such as correctional services. For these customers there’s strong legal requirements for data handling so a database super user with full access is a big no-no even for the most trusted developers internally.
We completely understand. We want to have the ability for Mathesar to gracefully handle DB users with different permissions (i.e. we'd disable features in the UI based on the permissions of the DB user set up during installation), but we couldn't get that done in time for launch. We'll continue working on this.
At the moment, the only installation method we support uses Docker, which requires elevated privileges on most systems. We're probably going to reduce the privileges needed for some macOS installations in the near future, since Docker runs differently there.
I like the idea of being able to track multiple data migrations or schema changes in parallel. We do currently support basic point-and-click DDL, and the data gets migrated when you (for example) set up a linked table based on some columns from an initial table, but we don't really have a way to track multiple such requests in one view.
I suppose one general solution would be to provide a UI for `pg_stat_activity` or other similar system tables that lets you filter easily.
I did try with some of the smaller sets, though, and they seem to work. An advantage of Mathesar is that you can always self-host, and provision enough resources for whatever data size you have!