That is exactly my early goal.

Currently, the column based access should help limit modifications to only specific columns. That said, I have heard this feedback and definitely have started thinking about an approval / pull request based workflow.

For some more context, when I worked at a large organization, any manual changes that were being made via SQL commands or CLI commands were sent through our code review system first.. and these were being done by developers. So by enabling a similar paradigm with a UX for non-developers, I think you're on to something here, good luck!

The problem you described at.that organization could have been solved with a policy change though. No need for a new SaaS product.

And if the policy didn't change, this product wouldn't help: Why would they have let people make immediate changes via web interface if things were so tightly locked down?

Does this not limit the speed and agility at which some organizations operate? Non developers should only be granted access to the tables that does not lead to a breaking change.

>they can easily make breaking changes

this can be mitigated with roll-back scripts

In many organisations, a break in a system holding production data is serious even if it isn't a serious break, so being able to roll back or otherwise undo would not cut it.

Much better would be to give them a replica to work on and a change confirmation process that allows signed-off changes to be pushed into production.

As another idea, since all the changes are described in an AST, I could offer a "undo" in the query log for INSERT action. The UPDATE action would require a bit more work as I don't track the previous data (and it could be changed in another system as well).