The PostgreSQL business

[Posted August 2, 2006 by corbet]

Back at the beginning of 2005, Pervasive Software decided that there was money to be made by selling support services for the PostgreSQL relational database management system. It seems like a good idea; PostgreSQL is a rock-solid system, increasingly fast, offering a number of interesting features. It is running in no end of production environments - including, it should be said, on the LWN.net server. Free RDBMS systems look poised to create trouble for their proprietary competition just like Linux made life difficult for proprietary Unix systems. PostgreSQL is clearly around for the long haul, and looks like a winning bet.

Not for Pervasive, however; the company has just published an open letter to the PostgreSQL community stating that, while the company remains a big fan of PostgreSQL, it is getting out of the PostgreSQL business. The money, it seems, simply wasn't there. Pervasive is not the first to come to this conclusion; a few years ago, a company called Great Bridge failed with the same model, despite employing several high-profile PostgreSQL developers. Red Hat still offers its version of PostgreSQL, but the last posted news for that product is dated November, 2005, and the product is not mentioned anywhere in Red Hat's last annual report.

PostgreSQL, it seems, is a hard business. According to Pervasive, the problem is that the free support is just too good:

While we always knew that PostgreSQL is a solid product with advanced database capabilities and that it has a very real opportunity to shake up the high-end database market, we underestimated the high level of quality support and expertise already available within the PostgreSQL community. In this environment, we found that the opportunity for Pervasive Software to meaningfully increase adoption of PostgreSQL by providing an alternative source for support and services was quite limited.

It is true that the PostgreSQL community is capable and helpful; any company which wishes to offer something better than what the community provides has a very high standard to meet. But there almost certainly has to be more to it than that. MySQL AB has had a fair amount of commercial success - something which companies working with PostgreSQL have not been able to duplicate. One might guess that the PostgreSQL community is more helpful than the MySQL community, and, as a result, there is more commercial opportunity in the MySQL realm. This does not seem like an idea that is likely to go very far. Something else is happening.

Perhaps commercial PostgreSQL support is simply an idea whose time has not come. Most PostgreSQL users may still be early adopters - people who are willing and able to handle the support details themselves. The larger market of users who are more interested in buying support services, perhaps, has simply not developed yet. To the extent that this hypothesis holds water, the companies which have tried to create a market in PostgreSQL services have not done an adequate job of selling its merits to potential customers. That would indicate that more work has to be done to spread the word on what a good product PostgreSQL truly is; there needs to be a serious brand-building effort.

There is another factor which should be taken into account here, however. Much of MySQL AB's success does not come from support services; instead, it comes from licensing. The MySQL code is licensed under the GPL, and the copyrights are all held by MySQL AB; as a result, MySQL AB is able to offer proprietary-style licenses to companies which wish to use MySQL, but which do not wish to license their own products under the GPL. PostgreSQL, instead, carries a BSD license and its copyrights are held by a number of different groups. So there is no "GPL exception" business model possible for PostgreSQL. Anybody wanting to use PostgreSQL in a proprietary product can do so without asking permission (or buying licenses) from anybody.

What all this means is that anybody trying to build a business around PostgreSQL must rely entirely upon services. They must convince potential customers that PostgreSQL is good enough to merit consideration over any number of proprietary alternatives, but not so good that these customers can support it themselves. The latter part should be relatively easy - there's still no end of customers who require support services before they will consider deploying a system. But convincing companies to walk away from their proprietary database vendors remains a hard sell. PostgreSQL, along with a number of other free database management systems, is a high-quality project. Eventually the commercial world will understand that fact, just like it has slowly figured out that Linux is worthy of its attention. But, until that time comes, making money from PostgreSQL will be a challenging task.

to post comments

The PostgreSQL business

Posted Aug 3, 2006 1:33 UTC (Thu) by dlang (guest, #313) [Link] (3 responses)

haveing recently gone through the excercise of trying to purchase support, one problem is that the companies (including pervasive) are not nessasarily looking to sell what people are looking to buy.

I was looking for support to back me up while we did an experimental project (with the emphisys on experimental, learing what works and what doesn't, purchasing X hours of expert assistance), for the most part the vendors (and I'm sorry to say including pervasive) were looking to sell a tightly defined project, that once it was fully specified (with all the details that we were intending to learn during the experimental project) would then march forward and be implemented.

unfortunantly most people who already know the answers to all the questions (including such things as 'what, exactly, do you want the reports to look like and contain', and 'how frequently they should be generated') have probably already done an experimental project to learn these things, and those people are probably going to continue useing whatever database they used for the experiment (unless the experiment showed that it couldn't handle the load).

anyone looking to offer support needs to be willing to work with customers trying to get their feet wet, those are the ones who can potentially grow to much larger projects. don't insist on makeing the initial project large and formal.

P.S. I'll also comment that there is no market for GPL exception licenses for the Linux kernel either, and somehow a large number of companies manage to survive supporting it, so it's not just a GPL vs BSD issue :-)

GPL and Business

Posted Aug 3, 2006 6:27 UTC (Thu) by GreyWizard (guest, #1026) [Link]

The GPL provides a substantial business advantage apart from alternative proprietary licensing: assurance that contributed code can't be used by others who hide further improvements. This is part of the reason so many companies contribute to Linux and GNU even though they compete with other contributors. Each knows the others can't release an improved product without making the source available and so must accept a level playing field. BSD and similar licenses are only more "business friendly" for companies that want to release proprietary software. For the overwhelming majority of companies who don't (and even for those that do in areas where they don't offer proprietary products) the GPL a better deal.

(As for wanting support for experimental projects that the PostgreSQL support vendors don't want to sell, I have had exactly the same experience. No doubt that's a tougher business than selling canned solutions or tightly defined products, but at least there is actually demand.)

The PostgreSQL business

Posted Aug 3, 2006 22:16 UTC (Thu) by chrism (guest, #4713) [Link] (1 responses)

One of the issues about providing "get your feet wet" type of support is that it's exceedingly hard
to make money at. It's "pure support". "Project" work is much easier.

Pure support presumes that there is an engineer standing by waiting for a phone call or at least
one that can get his head above water and in order to call a customer back within a day or so and
actually get started on something for them.

And a lot of times, you either need the customer to help you recreate the issue or you need
access to their system in order to work in an environment that matches theirs. And this takes a
good bit of time. In the end, it can easily turn out that "simple" problems can require one-day,
two-day, or three-day solutions.

So there's the need for someone to be standing by the phone ready to call someone back within
a day or so, but there's also an engineer spending perhaps an entire day or two helping another
customer with an issue. So really, at least two engineers are required to be sitting around to
service the optimal turnaround time requirement.

And Murphy's law is such that all the business actually comes in in clumps. It's never evenly
distributed. So you might have six customers at once who need something urgent one week and
none another. It *always* happens this way. So this tends to drive up the number of engineers
that are actually required to service "peak" customer load. So figure at least three engineers out
of the gate if you really want to meet your turnaround time mark.

Of course, engineers aren't likely to want to just get paid when they're actually helping someone,
they want to be paid for all the hours they work, even if there is no customer work to be done.
So you need to jack up the rate charged to customers to be able to pay for engineers' "sitting
around" time. This is why it's not uncommon to see hourly rates in the hundreds of dollars for
guaranteed-response-time support. They might not even be making much money off of these
seemingly astronomical hourly rates.

The wild card here is that people who use open source software are typically more hands-on
than their commercial software counterpart users. They tend to work through the simpler
problems and thus the problems that they call you with can tend to be harder to solve, so it's
typical that you need to hire *really good* engineers to do support as opposed to someone who
you can just train for a few months and put on the phone. Of course, really good engineers are
hard to find. And typically they really just don't want to be in a glorified help desk job, and even
if they do, they don't tend to be very good at it because they get distracted with "harder"
problems.

So keeping customers happy while still being able to make money and keep your engineers
happy is exceedingly difficult.

Just an observation. ;-)

The PostgreSQL business

Posted Aug 5, 2006 1:00 UTC (Sat) by dlang (guest, #313) [Link]

I don't doubt you for a second about how hard it can be to provide the support vs project work, but people need to recognise the difference between a company willing to do projects on X and people willing to do support for X

right now a lot of companies offering services are not clear on the distinction.

trivial typo

Posted Aug 3, 2006 6:42 UTC (Thu) by npj (guest, #4267) [Link] (5 responses)

s/Eventually the commercial the commercial world/Eventually the commercial world/

trivial typo

Posted Aug 3, 2006 16:10 UTC (Thu) by Zenith (guest, #24899) [Link] (4 responses)

s/Posting obvious comment about corrections/Mail corrections to lwn@lwn.net/

It has been stated several times, and trivial corrections like these (including my correction of your correct ;) ) only clobber the otherwise very useful comments from others.

trivial typo

Posted Aug 3, 2006 17:38 UTC (Thu) by edgewood (subscriber, #1123) [Link] (3 responses)

Yes, but it's not actually stated anywhere on the comment entry page, so a commenter would have to have seen that stated before, in another comment thread, and have remembered it from the last time they saw it.

trivial typo

Posted Aug 3, 2006 18:33 UTC (Thu) by Zenith (guest, #24899) [Link] (2 responses)

I am aware of this :)

Which, I guess, is an excellent excuse to write to LWN and suggest to add such a small note somewhere, and that I will do :)

trivial typo

Posted Aug 3, 2006 22:11 UTC (Thu) by giraffedata (guest, #1954) [Link] (1 responses)

I made that point in two previous threads like this one and got a response from Jon Corbet of, "we're working on it," so I can only assume updating the form is harder than it seems or the pollution of comments with typo reports is less urgent than it seems.

trivial typo

Posted Aug 3, 2006 22:35 UTC (Thu) by corbet (editor, #1) [Link]

It's not hard, it's just one entry on a very long list of things to do.

The PostgreSQL business

Posted Aug 3, 2006 8:21 UTC (Thu) by jhs (guest, #12429) [Link]

Having started a small and specialized consulting company; I appreciate the problem of offering a product the market doesn't want (Lord knows I have!). When determining what will sell, older companies can use their experiences; resourceful companies can pay for market analyses. Startups can do nothing except take on more risk.

Software without support is virtually worthless (see "Calculating the True Price of Software" at onlamp.com). Support means something that provides time, financial, and human resource guarantees to management so they can do budgets.

My theory is that Postgres itself is too low-level to be a product anymore. Only Oracle can still get away with calling a database server a product, and they are quickly evolving up to an "information company" while their low-end products are free to download. Today, a database is a hidden component of what customers really want: software or "solutions." MySQL AB does not sell MySQL as a product; they sell the right to re-use MySQL as a component, and that supports my point that databases are not a complete B2B product anymore.

I think there is a whole lot of paid Postgres support going on out there, but it is encompassed in the total support for some business application that ISVs and consultants deliver as a complete package. If an organization has the technical expertise to choose PostgreSQL on its merits; then it is not likely to spend money on Postgres support, when other software components are more buggy, more complex, and more visible.

pSQL lacks mindshare, distributed options

Posted Aug 3, 2006 8:45 UTC (Thu) by jgarzik (guest, #8364) [Link] (5 responses)

I have been a huge fan of PostgreSQL since its early days as Postgres95 (and even earlier university days). Unfortunately for me and other pSQL fans, two things are readily apparent:

"LAMP" has left PostgreSQL behind. There is IMO greater developer and admin mindshare associated with MySQL. More articles and tutorials describe how to get PHP going with MySQL than PostgreSQL.
Cluster immaturity. MySQL has been shipping a workable single-master replication+failover for quite a while now in most Linux distros. MySQL's multi-master solution, while requiring RAM (not disk) for storage, is also well-integrated and deployed in production.

In contrast, the PostgreSQL team has chosen to provide hooks for replication and failover. This has led to a situation where there are multiple projects supporting replications/failover, none of which are production-ready nor shipped in a modern Linux distro.

Modern systems must scale beyond a single computer, and the PostgreSQL support shipped in modern Linux distros is completely incapable of this.

pSQL lacks mindshare, distributed options

Posted Aug 3, 2006 9:13 UTC (Thu) by nix (subscriber, #2304) [Link] (4 responses)

I considered clustered MySQL a while back. I stopped considering it fast: the clustered-tables-must-be-entirely-in-RAM restriction is utterly lethal for all but the most trivial applications (or for those with the most insane amounts of high-end hardware).

PostgreSQL's clustering is weird and rather slow but it's better than *that*.

But perhaps my workplace's customers (big banks) have bigger datasets than most (they tend to grow and grow and *grow*). I don't know.

pSQL lacks mindshare, distributed options

Posted Aug 3, 2006 9:53 UTC (Thu) by jgarzik (guest, #8364) [Link]

Agreed, the entirely-in-RAM restriction of MySQL multi-master clustering is bloody awful.

pSQL lacks mindshare, distributed options

Posted Aug 3, 2006 13:11 UTC (Thu) by ll (guest, #4404) [Link] (2 responses)

It is "works out of the box" replication, not clustering, that is the feature lacking in Postgres. MySQL's is dirt simple and part of the core product. Postgres' is neither.

pSQL lacks mindshare, distributed options

Posted Aug 3, 2006 19:28 UTC (Thu) by AJWM (guest, #15888) [Link] (1 responses)

In that case it sounds as though, given the conclusions of the above article, that there's a market niche for someone to develop an out-of-the-box replication capability for PostgreSQL and license that code under the GPL, thereby "infecting" any previously-BSD pSQL modules that it touched.

Of course the more likely prospect is that someone spending money to develop said code would just as soon keep it proprietary. It takes a certain leap of faith (or low cost of development) to GPL code that one hopes to make money off of by alternative licenses.

GPL vs BSD

Posted Aug 4, 2006 14:38 UTC (Fri) by dank (guest, #1865) [Link]

The reason MySQL is able to offer a commercial
license is because it owns the copyright.
Postgres is owned by many contributors, so
even if it were GPL, that wouldn't fly.

But a GPL-licensed addon to Postgres that
*was* owned by one company or person might well
fly as a dual GPL/commercial license.
Hope somebody does this and succeeds.
It'd be hard, though, because it would probably offend
the entire Postgres community ("how dare you use
a different license?")

The PostgreSQL business

Posted Aug 3, 2006 12:19 UTC (Thu) by kleptog (subscriber, #1183) [Link] (4 responses)

I'd have to agree with the statement about high quality support from the PostgreSQL community. But the biggest problem I think is that it's a high quality product. Where I work we've used PostgreSQL since 6.5.something and while postgresql developers will tell you those versions were terrible, we had no troubles at all. Coming up 10 years later we've had a few version upgrades and it's gotten faster and more powerful every release. Yet all this time it's never crashed, never lost our data, never produced incorrect results.

Basically, I was in the position of deciding if we needed support. The answer was 'no', support for what? It was the most stable part of the system, outliving the hardware it ran on. When you have a system like that, what do you need support for?

Maybe one day the system will get large and complex enough that it needs more hand-holding, but that day is not here yet...

Sad to see them go though, it would have been great to keep them.

The PostgreSQL business

Posted Aug 3, 2006 17:44 UTC (Thu) by mikov (guest, #33179) [Link] (3 responses)

I second that. Perhaps the explanation is that PostgreSQL is a very high quality product. The documentation is amazing. It follows the SQL standards much better than competing open source databases. It is very extensible.

We have been using PostgreSQL for over an year and so far we have had zero problems with it and zero need for support. Even up to minor details like the latest versions always available for Debian stable in backports. If there is one piece of software that we haven't had to worry about in any respect, it is PostgreSQL.

Initially we evaluated several open source solutions - primarily MySQL, Firebird and PostgreSQL. We concluded that PostgreSQL was obviously the most mature and robust product by a significant margin, MySQL coming second, and Firebird a distant third turning out to be suprisingly inadequate.

It pains me that there isn't a more rapid commercial adoption of PostgreSQL, because ultimately that is the only way to guarantee continued development.

The PostgreSQL business

Posted Aug 3, 2006 18:09 UTC (Thu) by rise (guest, #5045) [Link] (2 responses)

I'll second this - there are definitely companies that need hand holding (or at least feel more comfortable if they're paying for it) or worry about having talent on call for a critical bug fix, but in the eight or so years I've been using PostgreSQL my problems have exclusively with my knowledge and solved by consulting the very extensive documentation. It's occasionally a little oddly organized (logical, just not my logic), but with the searchable and comment-enabled version on their site it's one of the best open source doc sets I've ever seen. In fact I'm not sure I've had even one error that could be attributed to the software itself.

In the non-bug space I know of one instance where a company hit a query optimizer flaw that hurt performance badly and ended up pushing for a particular new optimizer hint, but it was a very specific case and I don't know if anyone else hit it. Anyone who worked with Oracle a few years can probably tell you stories to the effect that their query optimizer was just one big flaw. I hope it's improved, but thankfully it's not my problem anymore. In general scaling is one of the big areas to call in consultants, and it's generally not as big an issue with PostgreSQL as with MySQL.

Overall I'd suggest that a big chunk of the support market problem is that the users who've chosen PostgreSQL are on average much more experienced that the MySQL crowd and thus far less in need of support with a very solid product. Not to denigrate the experienced MySQL users, but the sheer number of folks slapping up some PHP/MySQL app with no prior database experience is going to drag down the average user competence. Beyond the initial selection factor I've also seen a slow but consistent trend for experience MySQL users to move to PostgreSQL and zero transitions the other direction. That kind of filtering effect will tend to skim off a portion of the most clueful - perhaps not significant to the MySQL community, but enough to keep the average DBA/DBD quality reasonably good in new PostgreSQL users.

The PostgreSQL business

Posted Aug 3, 2006 22:58 UTC (Thu) by giraffedata (guest, #1954) [Link] (1 responses)

This article and all the comments are kind of vacuous due to a lack of definition of "support." I wonder what people are talking about when they speak of selling support for PostgreSQL.

Some comments imply support is fixing bugs in PostgreSQL. Others suggest it is building a system based on PostgreSQL. Based on my own experience with PostgreSQL, what I would pay money for is to have someone upgrade my installations to a new release (the last time I did that myself, it was a substantial amount of work).

No matter how high the quality, I just can't believe a user of something as complex as PostgreSQL has no need for expert services of any kind in connection with it. And I also have a hard time believing the mailing lists have been covering that entire need free of charge.

The PostgreSQL business

Posted Aug 5, 2006 1:40 UTC (Sat) by mikov (guest, #33179) [Link]

For me support means notification of important upgrades and security fixes, tuning, fixing problems (including bugs), and answering questions. I don't expect it to include someone actually working on my systems for extended periods of time. It sounds more like you should hire a temporary contractor for that.

There is a level of disagreement here about who is the end user and who is the user of PostgreSQL. End users typically require support, but they are not working with the database engine directly - they are using a product, and presumably receiving support for the entire product from whoever provided the product.

Incidentally this is what my company does - we support our own product. We'd actually strongly prefer it if our customers didn't tinker with the database directly at all. Theoretically speaking they don't even need to know that it uses PostgreSQL.

A company providing support for PostgreSQL specifically would be in a somewhat funny position of supporting something which they did not develop and do not control. So, unless they hired the main developers of PostgreSQL to work for them, the company ultimately will have to resort to the mailing lists.

So, if I needed support myself, I would just cut the middle man and go to the mailing lists directly :-)

Better Advocacy

Posted Aug 3, 2006 15:05 UTC (Thu) by tjc (guest, #137) [Link] (1 responses)

PostgreSQL could benefit from better advocacy. Too often it takes the form of enumerating the shortcomings of That Other Brand with a very negative tone. This comes across to neutral parties as sour grapes. Enumerating the benefits of PostgreSQL with a positive tone would be more effective.

Better Advocacy

Posted Aug 5, 2006 9:36 UTC (Sat) by flewellyn (subscriber, #5047) [Link]

This is a good point, which is why I often try to advocate for PostgreSQL using positives. Basically, I tell people who ask me why my company uses PostgreSQL that it's simply the best free database system available, in terms of features and performance being comparable to Oracle's offerings. When asked for specifics, I give the following:

Stability, by which I mean both "does not crash often" and "does not change incompatibly". PostgreSQL is a very stable, mature product, and quite robust. Since I orchestrated my company's move from Microsoft SQL Server to PostgreSQL over a year ago, the number of crashes of the database server has decreased from once every three days to precisely zero times. I am discounting, of course, the one time when the server machine itself crashed...but even in that situation, the database itself restarted without any problems. Furthermore, its external interfaces, the SQL language it uses and procedural language add-ons, remain compatible even between major releases.
Excellent performance. The database is fast, and remains fast even when scaling up to very large datasets in multiple databases with many concurrent accesses by many users. Again, I have seen this in production use. We pile on more and more work onto Postgres, and it just ticks along. (Other databases are known to be faster at small, simple workloads, but those databases do not scale up well at all.)
Good SQL compliance and very powerful query features. Postgres can do complex queries involving lots of subselects, complex joins on many tables, powerful transactions (8.1 even has save points within transactions that let you roll back to that point, rather than cancelling the whole transaction!), and its use of multi-version concurrency control (also found in Oracle, but done badly) means that most of the time explicit locks aren't even necessary.
Extensibility. I think this one is the most powerful feature. The whole database is extensible, not just with stored procedures, but allowing you to introduce new types, operators, type casts, index types, and others. You can add rules to tables that run additional queries or call functions on events like selecting, inserting, updating, and deleting rows (I use this all the time), and all kinds of stuff can be done with triggers and views. Plus, libraries can be loaded to add new features; one we make use of heavily is PostGIS, which adds spatial features to the database. Just about any database feature can be added using this extensibility; if a feature doesn't exist in stock PostgreSQL, it's comparatively easy to add without having to hack on the source code itself, just using the procedural languages and C API.
GREAT documentation. Others talked about this upthread, but I want to reiterate: PostgreSQL's manuals are the best I've seen in any free software project, and much better than many commercial projects (SQL Server comes to mind...). They're clear, well-organized, have good examples, document every detail, and are kept current. I have never had a problem following the documentation and getting different results from what they led me to expect.
And finally, the community is really supportive. Standard "tech support" is available just through the mailing lists, and if the question hasn't been asked before, someone's always willing to answer a polite inquiry.

All this and it's free software, too. What a deal.

Self-support

Posted Aug 3, 2006 16:30 UTC (Thu) by thyrsus (subscriber, #21004) [Link]

First of all, both MySQL and PostgreSQL are excellent pieces of software; they do offer different feature sets, so one needs to choose what fits one's requirements.

I have a suspicion that most who are sophisticated enough to choose PostgreSQL over MySQL are also sophisticated enough to succeed with a combination of community support and their own expertise.

The dual licensing of MySQL strikes me as odd: does MySQL AB obtain copyright transfers for bug fixes and contributions from the community? Or has everyone agreed to ignore the copyrights of community contributors? E.g., suppose someone other than MySQL AB contributed a GPL component that allowed replication of on-disk tables. Does MySQL AB negotiate a separate licensing agreement with that author in order to offer the component as part of its commericial offering? Are there other projects that dual-license? I'm familiar with the Perl dual-license, but what about commercial projects?

The Big Lie

Posted Aug 10, 2006 21:29 UTC (Thu) by sailor_moon (guest, #39799) [Link] (2 responses)

The postgresql has misrepresented the maturity and reliability of their product from day one. Back in 1999, the postgres documentation contained a long rant about how the open source development model made their database better than Oracle in every way. An endless stream of trash talk against mysql persuaded me to try postgres. A simple group by query took two hours,
and it took less than a day for me to get my first corrupted table. I picked up mysql, found that it could do the same GROUP BY in one minute.

In 2001 some friends of mine were using postgresql for a site that got bursty traffic. They had postgresql processes going bezerk and consuming 100% CPU, and had to write a program that kill -9'ed them.

I've had horrible problems with Postgresql 7; I've spent days trying to reload SQL dumps, and discovered that version 7 would accept garbage SQL queries that don't make any sense. Although pg 7 had a lot of good features on paper, it was missing a lot of practical things you need to make real apps: for instance, if you write a query like

select employee_id,sales from sales_statistics order by sales desc limit 10;

to see the top ten sales people, it would ignore the index on sales and do a full table scan. That's not scalable... That's not a database that's ready for the enterprise, but the pgsql hucksters were saying that pgsql was a competitor for Oracle.

PG 8 is a decent database. I've got a lightly loaded instance I need to kick once a month, but I'm not getting corrupted tables, so I can't complain. (Funny enough, I've got a heavily loaded mysql that I never need to kick...)

Often people forget the real difference between pg and mysql. Mysql is a commercial database like Oracle... There is a company that develops and maintains Mysql to make money off it; unlike Oracle, they give away the source... like Oracle, they make big $$ on support.

Postgres is more like somebody's science project. That's not all bad, because there is a lot of really cool technology in it, particularly in the "contrib" directory. Full-text searching in pgsql is harder to set up than in mysql, but it's much more flexible; the general-purpose index engine underneath it is great.

Personally I've seen a lot of inexperienced people get sucked in by the hype around pgsql, and dissuaded away from mysql by the trash talk that comes from the pgsql camp. I've seen some project failures, and I've seen some people switch to mysql. I've seen people get ordered by their boss to switch from mysql to pgsql and discover that pgsql can't handle 1/10 the load of mysql.

People who want a supported database are going to use a supportable database such as mysql or Oracle. People who like playing around with a science project will be delighted with pgsql.

The Big Lie

Posted Aug 12, 2006 0:49 UTC (Sat) by Baylink (guest, #755) [Link]

> The postgresql has misrepresented the maturity and reliability of their product from day one.

"The postgresql"?

Who's that?

The Big Lie - comments

Posted Aug 13, 2006 6:03 UTC (Sun) by gguugg (guest, #39846) [Link]

I'll try to make a comment on all your points in your letter. Here we go:

Rant about open source in the 1999 doc
-----------------------------------------

I didn't use postgresql 6 so I don't know if the doc back then contained a rant about open source. Postgresql 6.4 was released 1998 and I did browse it a little to find the rant but I couldn't. Here is the 6.4 doc if you want to look for it:

http://www.postgresql.org/docs/6.4/static/postgres.htm

Speed
---------

It sound like you didn't get your postgresql installed as you should have.

Postgresql need to run a VACUUM ANALYZE command regularly which clean up old stuff and more importantly update the statistics about the values in each column. This statistics is used to plan queries and is vital for performance. In the latest version of pg there is a built in autovacuum option but in the old ones you needed to setup a cron job that started the vacuum analyze each night (or some other interval depending on how much updates the database got).

You had an example query:

select employee_id,sales from sales_statistics order by sales desc limit 10;

which you claim didn't use an index. And that's just wrong. The lack of running VACUUM ANALYZE is probably the explanation. Postgresql have always used indexes for such queries for me.

Postgresql has an advanced and general aggregate function support where you can write your own aggregate functions. Back in postgresql 7 this made queries that used MAX/MIN to not use an index (for the min/max, other parts of the query could make it use indexes). Nowadays MIN/MAX do use an index. Back then this was a FAQ and the recommended solution was to rewrite a MIN/MAX query into

SELECT foo FROM bar ORDER BY foo LIMIT 1;

just because it did use an index. This is the exact same form as the query you claim didn't use an index.

The one and only explanation I can come up with about your performance problem is that you didn't manage to get postgresql properly installed with the needed cron job.

I agree that it was a problem that you had to setup a cron job. But it wasn't that hard back then either, all you needed was a cron job that called the vacuumdb executable.

Garbage queries
--------------------

You claim "version 7 would accept garbage SQL queries that don't make any sense". Do you have an example of that? I've never seen anything like it, so please, if you have an example, show it.

Corruption
----------

The talk about table corruption makes you sound like a troll. If it's something postgresql is known for, it's to protect your data and not corrupt anything. If you follow the postgresql mailing lists you will see that there are not many bug reports about corruption, and the few that are always gets a lot attention from the developers. If you search the archive you will see that when someone have corruption the developers most often ask them to run memtest, check the kernel log for hard disk problems and such. In a lot of cases the hardware problem explain the corruption right away. Pg checksums each data page written to disk, so memory/disk failure are often found right away when the checksum fail and then postgresql give an error instead of returning corrupted data. You would be surprised how often this have detected memory/disk subsystems with errors.

But it's kind of hard to say something about your experience, if you claim you had corruption I assume you did have some problem. All I can say is that my experience is the complete opposite.

Scalability
---------------

In every test I've seen it's postgresql that scale much better than mysql while mysql is often faster when you have very little concurrency going on and when the queries involve seq. scans.

The latest test I've seen is this two week old article: http://tweakers.net/reviews/638/2

Once again I guess it's because you didn't run VACUUM ANALYZE regulary as you should have.

Conclusion
-----------------

It's sad that you have had a bad experience, but I don't think it's the experience that most of us have about postgresql.

PS. Pardon my English. It's not my native language.

The PostgreSQL business

Posted Aug 21, 2006 2:35 UTC (Mon) by linuxpoet (guest, #40009) [Link]

It is quite possible to make very good money at PostgreSQL, and at only PostgreSQL. I refer to http://www.commandprompt.com/ who has been doing it for a very long time. Profitably, I might add.

The PostgreSQL business

Posted Aug 21, 2006 7:01 UTC (Mon) by dfetter (guest, #40012) [Link]

As a person who's been making his living at "the PostgreSQL business" for the past five years, I'm a little bit mystified by this article. It's true that the copyright holders of PostgreSQL aren't extorting money from users through a noxious, legally murky licensing policy. We used to call such arrangements shareware, and shareware earned its reputation for rotten code and shoddy service many times over. It's also true that those same copyright holders--the actual developers of the software, unlike those at any closed-source or shareware outfit--make a decent living at it but not an obscene profit.

The real question is, does PostgreSQL have *any* competitors in FOSS? Firebird's ten or so vocal adherents think so. SQLite's users understand quite well that SQLite is not a PostgreSQL competitor. In fact, there's a lot of mutual respect and understanding between the SQLite and PostgreSQL communities. Apart from those two and the above-mentioned shareware outfits, what is there?