Where I work we have an ESB to which 6 different applications (or should I say "endpoints") are connected. Those 6 applications work with 3 different Oracle schemas on 2 database instances. Some of these applications coexist in the same schema not because they are related but because our database infrastructure is managed by an external provider and obtaining a new schema just takes forever (also, we don't have DBA access of course)... It really takes so long that at one point we thought of reusing an existing schema "temporarily" to be able to continue development. To enforce "separation" of data, table names are prefixed, for example "CST_" for customer. Also, we have to work with a schema that for some valid reasons we cannot absolute change... It's strange I know. Of course, as it always happens, "temporarily" has changed into "temporar-namently" if you know what I mean ;-)
Our different applications connect to their respective database schema and work with their own PL/SQL packages and we absolutely forbid ourselves to interact directly with tables/data that is outside our application domain.
When one of the application connected to the ESB needs information outside from its domain, it calls the related service on the ESB to obtain the data, even if that information is in fact in the same schema, requiring in theory just a little join statement in one of the SQL requests.
We do that in order to be able to split our application domain into different schemas/databases, and in order for the services on the ESB to still work properly when it happens (it's Christmas soon, we're corssing fingers)
Now, this may look strange and awful from the outside but there are reasons to that and I just wanted to share this concrete experience to show you that one or more databases is not that important. Wait, it is !, for many reasons (+1 for Scott Whitlock, see last paragraph about backup and such that mya lead you into trouble) But it is equally important I think to have your SOA services being properly designed, at least that is my opinion, and I'm not a DBA. Ultimately, all your databases belong to your "enterprise datawarehouse", right?
Finally, I won't rephrase Scott Whitlock's last paragraph, particularly this
I wouldn't separate tables into different physical databases just because of separating concerns.
is really super important. Don't do it if there is no reason.