That's completely untrue and glosses over the very real costs of transaction management in such an environment.

Using a shared database allows you to punt a lot of that complexity to a system that's been specifically designed for it, and working well for probably 20+ years.

Too many people think microservices don't have their own, severe, downsides. The likes of netflix, google, et al, can afford to pay people whose entire job is to manage the complexities of these approaches that flat don't exist in other scenarios.

But it's a hell of a lot simpler to use a single database if you can get away with it.

Shared database can be a reasonable microservice boundary, especially when using database-as-queue or database-as-mucroservice. In the former, services a, b and c can insert and query but only D can update, i.e. any service can creat a work-order but only D can mark it completed. I. The latter, nobody can read or write and all access to tables is done through stored procedures.

I don't recommend either, and it's still a code smell, but with clear definitions they can work.