Is Drupal + PostgreSQL a reliable combination?

Events happening in the community are now at Drupal community events on www.drupal.org.
mickh's picture

I have a simple Drupal 6.4 installation running on PostgreSQL 8.1.6 (because that is what ships with Centos 5).
So far so good. However, I am evaluating Drupal for use with a large local government website which will probably grow quite complex.

How likely is it that we will run into problems using PostgreSQL with Drupal? For us, PostgreSQL is the non-negotiable part. We can always use another CMS but we have ruled MySQL out in favour of what we believe to be the more rigorous, capable and standards-compliant database.

Are we asking for trouble using Drupal with PostgreSQL?

Comments

depends

catch's picture

Drupal core should run pretty well with PostgreSQL - there's occasional bugs, and they usually have patches waiting to be reviewed by people who run PostgreSQL - see Patches needing review on PostgreSQL. Once you get into contrib modules, then things are less guaranteed - it depends very much on the maintainer. You need to be careful selecting contrib modules regardless of your choice of database anyway. However most will welcome patches for PostgreSQL compliance, so if you're prepared to chip in and help, then you should be fine.

I have had a production site

creativepragmatic's picture

I have had a production site running on PostgreSQL 8.2.3 for over a year now with no problems. As 'catch' said, some of the less popular contributed modules may not support PostgreSQL. In most cases, patches are pretty easy to create and contribute so you should be fully functional with little effort.

Also, Drupal 6 was a great

mikl's picture

Also, Drupal 6 was a great boon to PostgreSQL-support in Drupal, since the schema system absolves module developers of the burden of having to write different install code for each database.

Mostly the rest of the SQL code used in modules are simple select queries and the like, so its gotten much better since Drupal 5.

OK, so it looks like any

mickh's picture

OK, so it looks like any problems won't be a show stopper. I am a reasonably competent programmer and should be able to fix and patch any issues, and would welcome the opportunity to contribute patches if we go with Drupal.
I'm wary of building a site that depends on too many contributed modules anyway, our "enterprise" environment demands a conservative approach so we'll be sticking with bog-standard core modules as much as possible, apart from our own custom stuff.

modules and modules

catch's picture

Not postgres specific, but there's some modules which have as good code quality as core (better in some cases depending on which bit of core you're talking about), and some that are real shockers. So don't be put off contrib altogether, just be prepared to spend a little bit of time researching. If you'd really like to help out with patches and testing etc. a warm welcome awaits you in #drupal on irc.

Well I've just had a brief

mickh's picture

Well I've just had a brief look into Joomla - no PostgreSQL joy there, it seems to be totally a MySQL shop. There were several old forum threads around about adding PG and/or cross-database support, but nothing concrete seems to have come of it. It would be months and months of work by the looks of it just to get the basic framework working.

The CMS we're moving away from is eZpublish, which has reasonable PostgreSQL support but almost no user community, is overly complex to administer, and is an utter nightmare to develop with (but expensive paid support is only a click away ... hmmm).

So Drupal is looking more likely as our choice. I prefer OOP (Joomla and eZpublish), but am not such an ideologue that I'd go through the pain of Joomla or eZpublish to have it.

Apart from code quality, we're also concerned that if we rely on contrib modules they might not keep up with core development and we might get caught with broken or insecure modules.

If you're going to use

nileshgr's picture

If you're going to use contrib modules with PostgreSQL, it is necessary that you know reasonable amount of PHP and ANSI SQL. Recently I had created a patch http://drupal.org/node/702340 for that module coz it was not working with PGSQL 8.4

Its pretty easy to create patches though if you know PHP and ANSI SQL (PGSQL follows strictly ANSI SQL).

Regarding testing and

mickh's picture

Regarding testing and patching etc, I recently acquired a decent virtualisation server which would be useful - Dell Quad core Xeon with 4G RAM and around 1.8TB RAID5 array, running Xen on CentOS 5.2 (PHP 5.1 and PG 8.1 by default). The link above doesn't give me a great overview or insight into the testing and patching process, are there any other more general links on the topic? I'm probably not so keen on working with anything other than D6 and D7. Actually, given how quick Drupal evolves, maybe even just D7!

reviews

catch's picture

You can start with http://drupal.org/patch and http://drupal.org/patch/review

Active core development is all in D7 apart from backports, contrib development is 90% in D6 at the moment.

An advanced search of the core issue queue for postgres will find some relevant issues too, for example postgres gives me this list.

Postgresql

Group organizers

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: