<devils-advocate> A smattering of thoughts: 1. Nice Catch-22 or Chicken-and-Egg situation we have here. It's sort of like the push for PHP5, only that kind of effort is more the Postgres community camp. 2. Not many Drupal sites use Postgres, so why support them? Maybe there would be more, if we supported Postgres. 3. About the time MySQL reaches version 6, it will have roughly a comparable feature set to Postgres 7 (more than 3 years old, now). 4. For every feature we use that is easier or better in MySQL than in Postgres, there are items that are easier or better in Postgres. We just haven't taken advantage of them. 5. Not wanting to abstract the differences away between databases is partially built upon the conceit that all Drupal developers are good SQL developers as well. In reality, the vast majority of us should never write a line of SQL; instead we should be asking a Drupal API to fetch/replace an object for us. In practicality, that will never happen, as it has adverse effects outside the quality of code (e.g. the volume of code, novel new applications, etc.). 6. Regarding previous remarks about the slippery slope and chx's demand for some evidence: you should know better, chx. The evidence is simple and obvious: if we code specifically for one database (one browser, one screen size, one RSS reader, one whatever), the effort to then open up and use others at a later date is much larger than if we always coded with that thought in mind. My stomach hurts; I'm feeling grumpy. </devils-advocate> Wasn't there once an effort to provide an sqlite version of Drupal? :-)