PostgreSQL pattern to split a shared-database into a database-per-service pattern What would be your recommendation to move from a shared-database pattern, to a database-per-service pattern. In a production database with as little downtime as possible?

This would be only considering the database splitting part, the application logic split would be a different concern.
Pattern: Database per service


That's a horrible idea. PostgreSQL has schemas..

I suggest ignoring that author entirely. That whole article is trash.


  Development time coupling - a developer working on, for example, the OrderService will need to coordinate schema changes with the developers of other services that access the same tables. This coupling and additional coordination will slow down development.


How does two developers developing in different schemas vs database slow down or speed up anything? The only advantage is the planner can make use of the indexes and you can do cross-schema joins and operations.


  Runtime coupling - because all services access the same database they can potentially interfere with one another. For example, if long running CustomerService transaction holds a lock on the ORDER table then the OrderService will be blocked.


That's only possible if "CustomerService transaction" uses "OrderService". If it does not use "OrderService" you can not have that problem. Moving to a configuration, such as splitting the data into discrete databases, that makes such a thing impossible doesn't solve this problem. It just gives you more work to get there, and to get out of that mess after you're there.


  Single database might not satisfy the data storage and access requirements of all services.


What does that even mean? In any interpretation I can conjure it's even wrong. A single database in PostgreSQL can store different tables on different disks, but I'm not sure what the author even means.