There are many reasons to use two databases, some that come to mind:

1. Size (the limit of which is controlled by the operating system, filesystem, and database server)

2. Separation of types of data. Think of a database like a book -- you wouldn t write a book that spans multiple subjects, and you shouldn t (necessarily) have a database with multiple subjects. Just so all of the data is somehow related, you could keep it together (i.e. all the tables have something to do with one website or application).

3. Import / Export - it might be easier to import data into your application if you can drop and restore a whole database, rather than import individual rows into a database table.

Separate applications, or services. I can t see any reason to use separate databases for a single app/service.

(note: replication, even multimaster, isn t a separate database. Neither is Sharding.)

I believe some on here are confusing Database with a Database Instance.

Example: A phone book is a prime example of a Database.

Replication: having 2 copies of the same phone book does not mean you have 2 databases. It means you have 2 copies of 1 database, and that you can hand 1 to someone else so you can both look up different things at the same time thereby accomplishing more work at once.

Sharding: You could tear those phonebooks apart at the end of the white pages and the beginning of the yellow and hand them to 2 more people. You could further tear them at each letter and when you need susan summers ask the person with that section of the book to look for her.

suppose you wanted to publish or reuse some external database, and keep it separate from your primary database. This would be a good reason to use 2 databases... You can drop and reimport the external database at any time without affecting your database, and vice versa...

You can use two databases the same reason most banks have two ATMs, for reliability. You can swap one in if the other fails, but to do it quickly requires setup, such as a cname and controlling your own DNS server.

You can also do writes on one database, if the writes have complex triggers on them, and use some synching between databases to keep the second one updates, which is used for selects.

You can use two databases for load sharing, for example, use round-robin to split up the load so one isn t overloaded.

I sometimes have separate database because they handle different concerns. I.E. a Reporting database or an Authentication Database.

Replication

• Making your system scalable by devide your database system to different physical location
• Provide redundancy/replication as backup and seamless uptime.a

As Ben mentioned, Replication is one reason. Another is load balancing.

For example, Hotmail uses many database servers and customer data is broken up across the databases.

To have all of their customers data on one server would not only require massive storage requirements, but the response times would be horrible.

In other cases, the data may be separated by function. You may well have two sets of data which are either not connected, or at least very loosely so, and in such cases, it may make sense to separate that data from the rest.

Also consider IO needs. Writing to one, reading from the other. One with immediate transactional needs, others where "transactions" can be queued, one instance at high priority, the other at "idle" priority, &c. It is very obvious however with the correct hardware and tablespace/filesystem layouts most of these situations can be achieved in a singular DB.

I think SQLite databases on the iPhone is limited to a size of 50 megabytes, but you can open several databases.