Recently someone asked the old question about selecting data from different databases. This commonly comes up from users of MySQL, and the usual response is that they should put all the data in a single database in different schemas, and that a MySQL database is like a schema as the term is used by the SQL standard, whereas a Postgres database is like what the standard calls a catalog, containing many schemas. This answer is true and reasonable, as far as it goes. But it got me thinking a bit. One of my clients has a database that makes extensive use of schemas. They have a handful of huge tables that are public, and then a schema for each customer with some more customer-specific tables. The common data comprises about 80% or more of the total database size, even though it's a tiny number of actual tables. The way we have this set up works fairly well, but as their customer base grows the number of tables is getting bigger and bigger. It's doubled in the last couple of years, and the number of tables is getting to be a bit of an issue. It would be really nice if we could give each customer their own database, but we can't, because they all need this common pool of data. If somehow we could easily and efficiently access data from sibling databases we could do this nicely. So it's not just refugees from other databases who would like something along these lines.
It's mostly read-only. Yes we have a number of choices, and we'll be able to manages this, but none of them are terribly attractive. Consider this problem multiplied a couple of thousand times. If my client had a million clients instead of 500 or so to deal with, how would we manage this?