HN user
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.
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.
Mathesar dev here.
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.
The set of possible counterexamples has Lebesgue measure zero.