Microservices might be awful for all kinds of reasons, but your pull request problem is caused by your multirepo setup, not microservices. You can have microservices and a monorepo, for example.

Came here to say this. OP definitely has a problem, but not with microservices, it seems. Additionally, there are different levels of microservices.

Starting creating a communication pattern and separating concerns all the way to the table pattern they have setup, which does seem like overkill.

The former is useful in building teams, the latter is useful in dealing with scaling issues.

God be with the poor people who will have to maintain these systems in a few years when they are legacy and run on old tech. If you think maintains COBOL code is bad then this will be a lot of “fun”.

They will just re-write them in the framework or pattern du jour.

Jee. Sus. Why? What benefit did anyone think that would have? Better than half the point of using SQL goes out the window if you can’t query across tables.

Wait until you have half a dozen teams or other services directly accessing your tables and now you need to update the schema or data container for scaling reasons, but you can't because they don't have the time to update their access patterns. Or the team that thoroughly misunderstood how the data was to be used and built their tables and workflows on your tables, forever linking their structure together. Far better to expose data through APIs if you have multiple teams doing their own things in different code bases.

I’m familiar with patterns for divvying up DBs along lines of responsibility and access needs, but the described situation was one per table.