TLDR: Giving non-IT users direct edit access to the production DB will most likely break stuff. I wrote something similar to BaseDash ages ago, I called it dAg

TLDR: Giving non-IT users direct edit access to the production DB will most likely break stuff. I wrote something similar to BaseDash ages ago, I called it dAgent (for database agent). I had it running for many different clients from all sorts of trades (I do custom development). The GUI built itself from reading the DB schema. My initial motivation was to cut dev time since dAgent would automate the coding of CRUD interfaces. However, the use of dAgent in production ended up being quite limited: maybe only used to edit catalog data (i.e. add a city to the cities table). The reason for this limited usage is no mystery: one can easily break things. In particular non-IT users can break things. Allow me to use an example. You have a CRM with a customers table. On that table there is a field called status. For that field, dAgent would load a select input using the related table statuses, there was no risk to break integrity. However, in the business logic of this CRM, changing the status of a customer is the result of running a process. That process not only sets the status of a customer to a new value, but also writes a history log, sends email notifications and perhaps triggers an invoicing process. Now, imagine a non-IT user changing the status field of a customer using a tool such as BaseDash. Now you have a customer in status active who is able to login to your paid SAAS but has never being invoiced. Many such nightmares can happen when users can directly edit a DB. For this reason, in production, dAgent features where limited to CRUDing simple catalog tables. It did help, but was not the silver bullet I had hoped for. On the other hand, IT users would never adopt dAgent since the DB engine provided a much more robust and feature-rich admin GUI. I was not in the business of competing with PHPMyAdmin, so I eventually dropped the project.