I've been pondering a similar question myself. In my case, I'm developing a web app that will function as an online store-front, complete with user login, shopping cart, etc. So, basically every page hit is going to generate lots of database queries (session data, such as, is the user logged in? do they have items in their cart? as well as pulling items out of the inventory database for browsing). This is all great, in theory, but my web host provider has strict rules and regulations regarding how many computer resources one can use in a given month (disk, cpu, bandwidth, database access, etc.) I'm worried that I may go over my db limit with the current all-mysql implementation, so I'm considering using sqlite, or db_file, or something similar, that looks like a database in my code, but is really just a file on the server. This might work fine for small tables, sessions ids, etc. I've never seen anyone discuss issues related to partitioning up data this way, but I'd imagine it comes up frequently in practice, in shared hosting environments. In your case, sqlite might make sense in *some* areas, if not all.