In this approach, though the microservices are independently designed as a separate subsystem, they still share a single monolithic database, as follows:

Each microservice has its own set of tables, but all are part of a single database schema. The clear benefit of this option is simplicity, as a single database can be operated with ease. Also, transactions can be carried out in a more consistent way.

However, according to best practices, microservice should be independently deployable to get better scaling optimization. Another benefit of being independently deployable is the quick adoption of changes. As soon as multiple services depend on a single monolithic data store, this flexibility is reduced to take full advantage of the distributed environment, such as high cohesion and loose coupling.

Also, multiple teams generally work on the application side. They also need to face coupling with other teams while dealing with database changes. This will slow down the development and eventually add a delay in delivery. So, this is not an ideal scenario.