In addition to what other people said, the arguments under You should consider using this pattern if are all basically "you currently have a shared database and don't feel like splitting it apart."

The only bullet on the list which isn't related to "it currently works this way and you can't change it" is the one that says

> You want to maintain and operate only one database.

Which is frankly a terrible bullet point because the next question is "Why would someone want to do that?"

The whole list is basically just "if you have constraints that make a better design impossible then I guess you can do this"

That link seems to be making a strong case against using the same database for multiple services, without coming right out and saying it.

In the first paragraph, that doc echoes exactly what I explain.

> You need to carefully assess the application architecture before adopting this pattern, and make sure that you avoid hot tables (single tables that are shared among multiple microservices).

Using the same database table with multiple services (micro or not) is an absolute disaster.

Depends on the use case but all physical resources are finite in some limit so you may want to distribute that load so the different domain processes can scale appropriately. When/where/how is dependent on the application you’re building.