A little more detail about the "gotcha" that Jeff pointed out. You need pairs of triggers for each cross-database foreign key relationship: one trigger in the referring database, and one in the referred to database. The trigger in the referring database is pretty trivial to write. The trigger in the referred to database can introduce performance issues, and if you want cascade or similar actions on delete/update it can be quite a complex trigger.

In my experience, the gotcha has not actually been a problem, but that's because it's been possible to split the data into databases in such a way that cross-database foreign keys were not needed in the cases where I've chosen to split; that is definitely NOT the general case, so you need to make sure you are not buying yourself code complexity by splitting into separate database.

Of course the trade off here can be that splitting into separate databases with separate backup and DR plans can give you quite a big performance gain (for example if you can use simple error recovery for some of your data that saves the cost of doing log backups for updates to that part of the data, and if some of the data doesn't need to be recovered right up to date but can be a few days or weeks or months behind (perhaps because the loss is self correcting, as it often can be for archive data in a system that requires a few days/weeks/months of recent data in live as opposed to archived storage) the backup costs can be reduced still further. But you have no guarantee of such performance gains until you have carried out a detailed analysis of the effects of splitting the data on your system. And triggers are so easy to get wrong (for example most of the DBAs I've known have written single row triggers; so the system won't work if it uses any set-oriented operations; of course the DBAs can be educated to write triggers that cope with set-oriented operations, but you need to make sure that you the DBAs have that education since forbidding set-oriented operations is almost always a performance disaster.