Drupal 7 has a very interesting new feature which we call the registry. The registry holds information about which function, class and interface lives in which file. This information never changes if you do not change your modules and themes.
Drupal always had a system table which holds information on available themes and modules. This information never changes if you do not add new modules nor new themes.
If we put these tables in an SQLite table then the only time this file changes is when your code changes. Therefore, when people with high performance sites deploy their new code, they can deploy the new database. There is no new procedure to be created, just one more file
So, what you're roughly saying is: * the speed of a file read/parse of a SQLite table is always going to be faster than a MySQL/etc. read? Even if the above is true, I'm not a huge, huge fan of it myself. Is there an automatic backup in place - something that, if SQLite is enabled, but the SQLite database isn't there (or can't be created), we'd fall back to the MySQL version? Random comments and reasons for disliking it: * Not immediately easy to explain. What's this file doing here? Why is Drupal the only application I know that requires both SQLite and a MySQL store? Why isn't everything in MySQL? Why aren't more things in SQLite? * Generally speaking, "backup your databases" and "backup your site" happen in two separate mental processes (and usually technical processes too). Unless the feature handles a failsafe when the SQLite database goes missing, I'm not too happy with the idea of "ok, to backup the 'database' now requires a mysqldump AND a copy of this SQLite database." * Aesthetically, I like being able to see what's in a database. I don't personally know how to access a SQLite database, nor do I want to. * Similarly, in Drupal 6 (I dunno about Drupal 7), the system table is also NOT UPDATED when I *remove* modules or themes. I regularly am pruning it manually, because it bugs me. I'm obsessive about cleanliness and organization. Unless I move the DELETE FROM {system} code to a module, you're implying I can't do that anymore? * When I'm debugging, it tends to be useful to quickly modify up/down the weight of a module stored in, yep, the system table. Would I still be able to do that here, from a MySQL prompt? Or would I have to devolve into learning SQLite again, when I've never ever had to use SQLite ever? * Are the gains *really* so incredibly huge that SQLite is the only solution, as opposed to "just" throwing the same ol' chainsaws at the problem: memcached, opcode cache, etc.? If this is so great for high-profile sites, they've probably already got their own specific set of tweaks for improving things, no? (I know I do.) * "Therefore, when people with high performance sites deploy their new code, they can deploy the new database." Where is this new SQLite file being created? This particular comment, I dunno, feels ooky to me. When I deploy code, I want to, you know, deploy *code*, not a set of caches (for the same reason that I don't deploy memcache instances or previously opcoded cache files). -- Morbus Iff ( cheese and rice saves ) Technical: http://www.oreillynet.com/pub/au/779 Enjoy: http://www.disobey.com/ and http://www.videounderbelly.com/ aim: akaMorbus / skype: morbusiff / icq: 2927491 / jabber.org: morbus