I have worked in both kind of environments. I was an unconditional promoter of the shared-db approach. It took my some time to see its limitations and to reconsider: Envisage it only for tightly related applications working in the same bounded context.
In general the shared-db work very well. Like COBOL programs before them. And like them, they still makes us see data as something passive that waits to be processed by a software that knows how to deal with it (and that will do it right). Single-dbs have the advantage of letting application share enterprise data. Exactly as global data is shared by different modules.
But modern software engineering has learnt us to encapsulate modules, avoid global data, and go the OO way: data makes sense only together with the code that can handle it reliably. Why do we continue to ignore these principles at the database level ?
The graal of the single corporate database
Single-db work very well, because in a company, all activities are somehow linked. That's the principle behind many leading ERPs. Having everything in one DB allows you to integrate in real time different applications very easily.
- Reduced operating cost
- Opportunities to reengineer processes: all the data is there; so you are free to redistribute functionality between applications.
- Opportunity to rationalise the db design: End of the 80's beginning of the 90's I witnessed a couple of centralisation projects, with impressive reduction of the number of application software (in particular ETL/interface programs)
- Synergies: different teams share the same skills and can share ideas by communicating of their DB scheme.
Risks and disadvantages:
- The success will depend on the ability design the DB scheme from a global perspective, across the domains. If everybody continues to build a sandcastle in his/her own namespace, you'll have the inconvenience of the global DB without most of its advantages.
- Strong coupling of the components: you can no longer reuse an application in a different context (another site, another company), because data is intertwined with a lot of other apps.
- Unknown dependencies: Since everything is linked in one DB, and its easy to access a table in another scheme/namespace, the dependencies are not clear. This has of course an impact on the organisation of developments: are you sure that some db tables you tested with were not changed by some developer of another app ? How to organise the db evolution ?
- One bad behaved programme can create inconsistencies across the db
- Scalability is ultimately limited by the scalability of your DB engine.
- Slow down of innovation, in part because of fear ? Due to the unknown dependencies, most of the time SW-engineers will prefer not to touch a working production db.
- Vendor lock in ?
But aren't we in a different world now ?
Nowadays the trend is to avoid the monolith and to conceive flexible evolutive and scalable architectures:
- In our internet-aware world, application can communicate through webservices and no longer require a common db to exchange in real time.
- Microservice architecture even prone to avoid a shared DB: each (micro)-service is expected to have its own private DB, so to increase decoupling and accelerate deployment of new developments.
- Cloud operations let reconsider the operating costs under a totally different angle. You no longer care about how many dbs servers you need to patch, upgrade or backup: it's included in the price.
- NoSQL made it's way to the mainstream: many applications can work perfectly with an RDBMS. But there are specialized problems are better handled with different technology: a graph DB, a document oriented DB, or need for geolocalized sorting may favor specialized DB engine. One-DB policy would be a blocker.
- Some application don't need a DB. For example event streams process in real time large amounts of data between applications, without requiring the data to be shared on a db (the db equivalent would require inefficient repetitive queries to detect new data).
The key for a good architecture is no longer to define the right tables in a single db, but to define the right APIs, letting services make the glue between the different apps.
This being said, let's not be dogmatic. For tightly related applications working in the same bounded context, a shared DB is still a valid alternative.