The phrase "to have multiple programs share a database" says a lot about what school of thought one belongs to in terms of architecture. Using the database as

The phrase "to have multiple programs share a database" says a lot about what school of thought one belongs to in terms of architecture. Using the database as the integration point went out of fashion a bit over 20 years ago. And for good reason. It is not a good integration pattern. It makes the implementation the integration interface rather than using a tightly controlled abstraction that can be kept narrow and preserve degrees of freedom for future evolution. And as you allude to: it gets worse because you have to move more application knowledge and logic into the database to make sure applications don't mess it up. In fact, this approach is so bad that Amazon's CEO explicitly forbade it at Amazon (Bezos API Mandate, 2002). How often do you see CEOs, even of tech companies, find an integration pattern so counterproductive and dangerous they announce to the company that they will fire anyone using it? I would say that about 60-70% of projects I've worked on in the last decade have switched databases at least once. One project had support for 5-6 databases and used three different databases in production over a span of 5 years. Adding support for them had fairly low cost (because the internal design made it easy) and it gave us the opportunity to try several things in production, at scale, and then choose what produced the best results. This is a lot better than just choosing something up front and sticking with it because you'll have the data to make an informed choice.