When (not) should you use a shared database and do without API Gateway?

Question

Database

The customer suggests using a shared database under the pretext that we will spend more time developing with API Gateway and there may be errors / security issues.
The main application is responsible for all data, but from the user's side it can change * not all data. And only auxiliary (for example, it is for admins) can change the same data.
It is proposed to make a change directly in the database, in which I do not see any advantage. Synchronization of models (in sequelize.js), database administration in order to create the necessary users and grant them rights - this is not the whole list, but enough to complicate development.
What arguments to provide against such a decision? Have you experienced this in practice, and what are the advantages/disadvantages of this?

Answer 1

A lot of pain from what the customer wants from you. I sympathize. I would like to know right away - what kind of API Gateway are you talking about because there are several solutions on the market (I hope you do not do everything from scratch there)
In general, a shared database is a bad design. Yes, it works at first, and then the pain. Users generally should be in a separate system (Identity Server and all cases).
Since you are making an API Gateway, you need to understand that it is very good to do the client part precisely within the framework of interacting with the API. When you have several points of access to the same data directly from the database, this increases the complexity of support and is never linear. Especially if there is no documentation.
Deploying the solution will become impossible over time - you made a small change in one system, and it pulled it everywhere. It is much better to make different caches from the side of all applications, use the notorious GraphQL for aggregation and stuff like that.