PostgreSQL Fails a Red Hat User?

Winding it’s way through the blogosphere is this [http://blog.seankaye.com/archive/2005/11/02/866.aspx tail of woe] about a customer who attempts to make use of a Linux/Apache/PerlCGI/PostgreSQL based system for part of a high load web front end. The story goes on to say that they ran into massive scaling problems that required them to call in [http://www.redhat.com/en_us/USA/home/services/ Red Hat services division]… quoted with my commentary as: The new server needed a special patch written for it and had to go to an individual who is an expert in PostgreSQL to make sure it was all going to work. The community itself had been asked in the official forums for two months and no help or advice was offered. It took a couple of days for this guy to “bless” the patch. Now I am thinking this has to be Tom right? Seems like it should have been. But I am curious about the posts that were sent in to the community that were ignored. The community is usually pretty good about that stuff but it doesn’t always work out… I’d like to see the official posts to look at the quality / complexity of the posts. The other thing that Red Hat engineers altered us to was that in their experience they had never seen a PostgreSQL database as large as what we were dealing with and they were concerned about scalability and they recommended it be migrated to Oracle. In fact everyone made similar suggestions and one Red Hat person actually said, with Oracle, you don’t need Larry Ellison to approve your patching. The crack back is easily dismissed… in Oracle you don’t get to do patching, so it’s irrelevant. But what I am really curious about is, how big is this database we’re talking about? Or more correctly, how small are the systems that Red Hat is working on? PostgreSQL certainly scales to [http://www.computerworld.com.au/index.php/id;1482975508;relcomp;1 ginormous levels], both in size and in traffic, so I wonder just what kind of load are we talking about here. The poster goes on… So, overall the cost issue was a false economy. The software’s lack of scalability is dramatically impacting our ability to use the product and therefore severely limiting their revenue flow. The idea that anything running on Linux will scale better is a joke, I know if that database was running on SQL Server 2000 (nevermind 2005) it would have easily handled to load. Perhaps the biggest flaw was with the idea that the “community” is so ready and willing to help. These guys literally asked the official forums for help over the span of two months and got nothing of significance back – even a Microsoft NNTP group would get better results than that. More importantly, if they were using Oracle and having those problems, they could have just called Oracle and let them figure it out. There’s so many things here it’s hard to know where to begin. My experience, and that of a number of $QL $erver converts in the community, is that PostgreSQL can easily out perform $QL $erver, so did the poster really have some type of Linux vs. Windows problem? Furthermore, we have [http://archives.postgresql.org public archives], I’d really like to know the postings that were sent to the community, we’re open source here so please let’s see the links. And on the last note I have to say that, although Red Hat does provide critical development support to the project, I really am skeptical of thier services division (especially now). Maybe these guys just fell in with some pro-Oracle folks on the linux side of Red Hat. Or maybe they need to hire some PostgreSQL dedicated talent to do DBA / performance tuning / non-core development type work. I don’t know, but this is certainly not a good tale to hear. It might also be worth pointing out here that the user really didn’t go to a PostgreSQL company, they went to a Linux company, and that’s certainly a different matter than going to Oracle for Oracle support. I have a feeling that going to any number of other companies like [http://commandprompt.com/ Command Prompt] or [http://www.sra.co.jp/index-en.html SRA] would have seen better results, since thier core business revolves around making PostgreSQL work, which is really what was needed here.