I guess I just don't see the value in having a monolith made up of microservices - you might as well just build a monolith if you are going down that route.
And if your application fits the microservices pattern better, then you might as well go down the microservices pattern properly and not give them a big central DB.
The one advantage of microservice on a single database model is that it lets you test the independent components much more easily while avoiding the complexity of database sharding.
Where I work we are looking at it because we are starting to exceed the capabilities of one big database. Several tables are reaching the billions of rows mark and just plain inserts are starting to become too much.
Yeah, the at the billions of rows mark it definitely makes sense to start looking at splitting things up. On the other hand, the company I worked for split things up from the start, and when I joined - 4 years down the line - their biggest table had something like 50k rows, but their query performance was awful (tens of seconds in cases) because the data was so spread out.
99% of apps are best fit as monolithic apps and databases and should focus on business value rather than scale they'll never see.