Currently I'm doing an experimental Oracle port, and for that need I've done a quick travel in the drupal code... Frankly, I don't think PDO could be a solution for a better database portability, at least in drupal. From what I've seen, the database usage is pretty plain (some "create" in ".install" and mostly simple (only some table involved) "select", "insert" and "update" - or, better, "upsert" in the code). My first feeling was to create a very light db persistence layer, based on php dynamic object creation (__get and __set): define a class with an array on info like: name, type (number, text, large text and blob), is (part of) primary key, is indexable. Do a mapping into a "create table" should be easy. The actual common usage of "db_fetch_object" may be left more or less unchanged, simply creating queries asking what fields from what table with what filters. The "join" case can be simplifyed using views. About the db_num_rows question: there are more than a good reason to avoid it. As an example, the default behavior for the postgresql driver is to fetch in memory _all_ the results before returning the first one to the caller: with big tables this is simply devastating (and can be removed from future releases). And Oracle simply doesn't support it. My 2cents... Best Regards, Gabriele Turchi P.S.: I'm sorry, my english il alpha version...