Friday, May 02. 2008
Recommended Books: PostGIS In Action PostgreSQL 8.4 Official The SQL Language PostgreSQL 8.4 Server Administration
There has been a lot of talk lately about PostgreSQL and what MySQL can learn from the PostgreSQL clan. We would like to look at the reverse of that. This article is a bit of a complement to Joshua Drake's What MySQL (and really, Sun) can learn from PostgreSQL.
First of all a lot of staunch advocates of PostgreSQL wonder what exactly is it that MySQLers see in that beast of a database or as Martin Mickos likes to call it The Ferrari of databases?
For example, as Magnus Hagander pointed out in A new MySQL gotcha and we pointed out in SQL Math Idiosyncracies, MySQL's casting behavior is shall we say odd. I won't even recount our frustrations with using their ODBC driver with the MySQL 5.0 incarnations, but that could be ignorance on our part. Zack Urlocker of Sun has espoused, the upcoming MySQL 5.1 will have no bugs so perhaps this along with other bug complaints is a moot point.
So why do people choose MySQL time and time again over PostgreSQL and why is PostgreSQL sometimes a hard sell? Some of what we are going to say is a bit tongue-in-cheek so please don't take offense.
MySQL is pervasive and ubiquitous
Being pervasive and ubiquitous is a huge selling point.
How did MySQL get to that point and what tricks can PostgreSQL borrow from that experience?
PostgreSQL has a lot of selling points that MySQL lacks, but this is a talk about why MySQL is so great, so we'll save that talk for another day.
PostgreSQL people look like a gang of geeks and Martin Mickos looks polished
PostgreSQL clan is heavily loaded with geeks and the first thing that comes to at least my mind is geek when trying to summarize the generic face of a PostgreSQL user. This is a good thing from a development standpoint and for attracting great developers, but is bad when a large constituency you are trying to sell to are not geeks and they perceive your database as a thing that only a geek can use effectively. While we would like to think otherwise and at least think that its in vogue to be a geek, most people are not geeks. We need to sell more to the otherside of the fence - because like it or not - they are often the ones that make the decisions.
Martin Mickos is riding on what Leo likes to call People who look alike play together rule of social behavior. He is forced to wear a suit like most money-decision making people and looks comfortable in that outfit. He looks like a CEO. He might be a geek inside but he covers it well, and he gives you the polished feel that he can endure the torture of a CEO recounting his golf game or bragging about his greatness. Why is this important? Isn't it all an act? Yes it is an act, but it sends the message - I know how to act right - when to open my mouth and when to keep it shut. This is incredibly comforting to a generic CEO, CFO or CIO type. Yes it does often come down to he got the contract not because his technology was better but because he had a better suit on, got drunk on his own cool-aid and could finish a sentence without saying "Uhmm".
Martin Mickos balances Michael "Monty" Widenius disposition well, whereas a lot of PostgreSQL folk look and sound like Monty with very few balancing Martin's to level the see-saw.
We don't have a very strong prominent non-geek face to offset this imbalance. We need a CEO friendly imposter. I would say the closest are some of the EnterpriseDb folk, but EnterpriseDb is a commercial offering so that can only get the clan so far.
It would help if core PostgreSQL had a prim and proper looking figure or a comedian like Steve Jobs, Larry Ellison, Marc Fleury (founder of JBOSS), or geekesses in disguise like Kim Polese (the woman behind SpikeSource, Marimba, and Java) who exudes subtle persuasion abilities or a quietly confident woman such as Diane Greene, CEO and CoFounder of VMWare. Some PostgreSQL folks come to mind that can be molded into some of those type figures, but they still have that geek suit on (the T-shirt and the long hair that appeals to geeky sysadmins who are not always allowed to make decisions). Steve Jobs is a geek, but one with style. His brat geek kid who never grew up and with an obsession with clean interfaces that look good is great marketing. Similarly Larry Ellison's farcical obsession with wardrobe, racing, womanizing and destroying competitors is equally entertaining. Marc Fleury seems to be a compromise between the Steve and Larry personalities and some others mixed in. He has an air of mystique, but he knows when to behave as well.
Kim Polese perfectly complemented the advanced geekism of James Gosling who wanted to call Java a stupid name like Oak.
Diane Greene is an equally neat woman. She is not pushy, doesn't quite look like everyone else, but enough to make one feel comfortable, and she has that look that just screams - I can lead an army of ships into war. She balances out the more behind the scenes personality of her husband, Mendel Rosenblum, co-founder and chief scientist of VMWare.
Bill Gates (please don't throw stones at me for listing Bill Gates as one of those we respect). We for the most part like Bill Gate's and admire him. Both he and Diane Greene are what I shall refer to as anchors. Another rule of social behavior is that people like to hang around anchors. Anchors are those people who have a horned or natural instinct for feeling out what makes their audience comfortable and becoming it. They don't quite dress like their audience, but are not vastly different enough to be scary. They stand out just enough to look different, but not too much. They seem as content being by themselves as they do with being with other people. You only need to look at video of Bill Gates last full day to see what an anchor he is.
A lot of PostgreSQL folk, from a cursory observation, are suffering from some form of geekism and while it is not something that is easy to cure or should be cured - we need to offset it more with at least people who can hide their disorder or highlight those who have it to such a ridiculous level that it serves as a natural parody.
Symptoms of this disorder include
MySQL has a pluggable storage architecture
Now this one we wouldn't suggest bothering with, although we should probably dissect this thoroughly to understand better what value people see in this and what substitutions can be made and pointed out that PostgreSQL offers. Granted the camp is divided here. Personally the fact that some things are supported on one MySQL storage engine and not another MySQL storage engine makes MySQL somewhat unpleasant to work with. As Tom mentioned in his The Value of MySQL Storage Engines I suppose there is some charm that we just can't appreciate.
Log Buffer #96: a Carnival of the Vanities for DBAs
This is the 96th edition of the weekly review of database blogs, Log Buffer...
Weblog: Pythian Group Blog
Tracked: May 09, 12:57
Portable GIS: PostgreSQL and PostGIS on a USB Stick
First this is a windows only package, but nevertheless sweet. In our article What can PostgreSQL learn from MySQL? we complained about the fact that there is nothing like Server2GO pre-packaged with PostgreSQL. Low and behold comes this thing called
Weblog: Postgres OnLine Journal
Tracked: Jun 18, 08:49
Recommended Books: PostGIS In Action PostgreSQL 8.4 Official The SQL Language PostgreSQL 8.4 Server Administration
Display comments as (Linear | Threaded)
Regarding "Zack Urlocker of Sun has espoused, the upcoming MySQL 5.1 will have no bugs so perhaps this along with other bug complaints is a moot point."
Huh? Software with no bugs? Sounds like a marketing gesture to me. Where did you get this quote from?
Its in the eWeek Ferrari of Databases article we listed above. The exact phrase used was "This version now has zero bugs," Urlocker told eWEEK. I think what he meant was all bugs in MySQL bug tracker have been corrected.
> PostgreSQL people look like a gang of geeks and Martin Mickos looks polished
I'm curious just exactly which "PostgreSQL people" you're referring to here. The vast majority of the people who travel and speak keep both their hair and their words short and tidy. There are two people I can think of offhand who wear ponytails, and neither of them otherwise fits any "geek" stereotype.
I tend to agree with you that I think the pony-tail/geek argument doesn't hold too much water. I mean, Jonathan Schwartz, CEO of Sun, has a ponytail and bridges the professional and the geek quite gracefully. :)
However, I *do* think that the authors of this article are correct in that there is certainly an attitudinal difference between MySQL "advocates" and PG "advocates". The former, in my experience, tend to me more moderate and less dogmatic about theoretical things than their PG counterparts. The dogmatism and ideology of some PG advocates, especially in the arena of licensing (BSD vs GPL) and the arena of "pure relational DBMS" arguments have been a turn-off to elements of the broader technology field that are not DBAs by trade.
To put it in a one-liner, you will rarely find a MySQL user/advvocate say that "PG is crap". Instead, often they will say "PG is great, but different, and more complex". But the opposite, im my experience, is not true. I often run across blog posts and PG advocates that generalize "MySQL is crap. Use PG, it's a *real* database".
This attitude is a turn-off to a large segment of people.
Just my two cents. Cheers,
I would have to agree with Jay's thought about attitude. While it's not true for everyone in the pg community it is true for many. It's not even *just* against mysql. It's against every other database. It seems that if it's not done the pg way, it's not done the right way.
Okay I admit, the ponytail pick was a bit unfair. I guess I was thinking of the comic store owner guy in Simpsons whenever I hear someone in PostgreSQL groups make a snide remark about MySQL and other things. I admit I am not immune to this fault so part of it is a pick at me too. It just irritates me immensely when I see the reflection of my worst inner faults in others. :)
- e.g. "ah you were using that pedestrian database to do real work? No wonder you have problems." "STOP TOP POSTING!"
You have to admit that comparing being terse and to the point vs. being mean is like comparing apples and oranges. You can be very mean and to the point at the same time.
#2.2 Regina on 2008-05-05 00:47
This post reads a bit like a joke -- it's hard to take it seriously. Maybe that was done on purpose?
Anyhow, I'd appreciate it if you could elaborate on "...PostgreSQL has caught up there and is beginning to see the fruits of that labor." -- what kinds of fruitds of that labour is PG seeing? Could you describe that a bit more, please? Thank you.
#3 Anonymous on 2008-05-04 00:18
This is just from personal experience. We meant that before we'd have clients where PostgreSQL was a better option for them than say MySQL or SQL Server and it was a really really hard-sell to pitch PostgreSQL. For lots of things it really doesn't matter if you run MySQL or PostgreSQL or SQL Server.
Now we are seeing clients (even those running on Windows) that are already sold on PostgreSQL before they come to us.
#3.1 Regina on 2008-05-05 01:35
MySQL is popular for the same reason Visual Basic is popular, it is simple to get started with and you see instant results.
Take a fresh download of Postgres, the steps to get TCP/IP configured are not straight forward or obviously documented - MySQL just works.
Some of the non-standard features that make MySQL so poor in the eyes of a professional, actually help soften the learning curve of the database for those with little experience who aren't used to thinking like a DBA. As you get started on your first MySQL based project and start creating a schema, things like auto_increment are easy to get your head around.
And just as with many Microsoft extensions to standards, those features end up being a barrier to entry with other databases as you progress, keeping people hooked on MySQL and finding ways to make it work for them, rather than having to discard everything they've learnt to date.
Postgres documentation for those who are already literate in DB speak is very comprehensive and covers all the features. However there are two distinct gaps in the documentation:
1. Beginners guides, written in plain English, that explain the basic concepts and technical terms that people are going to come across, as well as taking them step by step through their first example project. This guide should really be database agnostic, but provide examples for Postgres.
2. A concept migration guide - there are lists of features that Postgres has that MySQL doesn't, and the like, but I have not found a guide that explains in simple terms what each of those features is, how to use them, why you should use them, and how they all fit together. Finding out the syntax for a particular statement is easy, but finding out how and why you should be using that facility is not covered.
I think that both these issues help reinforce the outsiders view that PG people tend to have an elitist attitude to non-PG people. I write this as a recent convert, having finally had enough of MySQLs limitations with an enterprise class project, that had started out small and grown beyond the DB's capabilities. I always looked at the feature set in PG with envy, but until recently I found the DB just too different for me to want to invest in making the switch.
Having no experience with PostgreSQL I will not engage in technical details but rather speak of my journey with MySQL. In the late 90's, my former boss decided to switch our SW to true SQL server. After many a discussion, choice fell on MySQL. At first, we were amazed with speed and ease of use. Later on, when problems surfaced, I was always able to get Monty or Sinisa on the phone and ask for advice. This was a great asset to us! Following on this, MySQL got from us one of the first Windows GUI client and numerous replies on windows mailing list once it was established. My point being you need quality response from community and to get that you need to invest a lot! Take a Jay Pipes for example (btw. Hi Jay!), MySQL community team consists of great professionals lead by one of the most important persons in MySQL. No compromise, community get's the best.
This brings me to, along with Chris's comment "1. Beginners guides, written in plain English", another point I wish to make. Although above seems unrelated, it is! What Marten brought to MySQL, besides looking sharp ;-), was enough money to be spent on community, support & docs team. It is my opinion that all three teams are of top quality in business. And only support makes money.
So, it doesn't seem right to attack MySQL over commercializing part of it's offers as most of the money goes back to where it should, to community.
To the authors, minority of one doesn't mean you're crazy! Although Nietzsche was well aware how hard that might be. Do not antagonize people for being fond of "anchoring", it is our nature. I have never met a vegetarian that didn't try to "convert" my eating habits ;-).
Finally, I'm looking forward to checking into PostgreSQL deeper, now that we're all part of SUN.
It's all about the name.
Well, no, it's not all about the name. But I wish it would change. It's not that it's really bad (not compared to the gimp anyway), it's just that it stumbles off the tongue, and it's not very memorable. "Howdyou say that now? Post Rest QL?"
Quite honestly I've recommended the use of PostgreSQL quite a few times when it was the appropriate tool but the name always seemed to be a bit of a stumbling block. When you're trying to pitch to a non-techy crowd, the name is more important than it ought to be.
It started as Ingres. Why couldn't it have been called Egress and saved me all this hassle? :-)
I agree too. Even Oak as stupid as it is slides off the tongue more easily. Saying PostgreSQL just doesn't make you sound like a smooth talker in meetings.
#5.1 Leo on 2008-05-05 00:14
I would like to raise one MySQL feature to the list, working integrated replication. PostgreSQL replication is a joke compared to MySQL one. Not to even get started with non-working PgCluster compared to very proven MySQL Cluster. Building high available, scalable systems is quite hard with Postgres, and that is a big problem if one wants to use Postgres for commercial applications.
Yes it's possible, I have setup DRBD + Slony replication for my company, but I used to maintain large MySQL replication and damn it was easy and better working.
#6 Toba on 2008-05-05 03:53
Thanks for the link. I'm happy to see others using S9Y. :)
I'm actually more a fan of PostgreSQL than MySQL. In fact, the only thing I like about MySQL is the pluggable storage engine option. If there's a way to do something similar with PostgreSQL I'd love to learn about it.
One comment concerning the lack of polished geeks promoting PG: Martin Mickos fits in with the business types because he runs a business. And that's really the key - the simple fact that there's a business behind MySQL makes it immensely more acceptable in the corporate world. There's a contract to sign and an entity to sue (if necessary), and that makes it palettable. Not so with PostgreSQL, at least not as far as I know. And until or unless that changes, PostgreSQL will never be adopted, officially or unofficially, as much as MySQL.
You are welcome Tom. I remember someone mentioning that way back when (e.g. maybe in the 6+ era) PostgreSQL had a pluggable storage engine, but the feature was discarded because it was too much trouble to maintain.
As far as contracts to sign and entity's to sue, I always thought most organizations are over that or at lest they are into suing consultants rather than software vendors. I can't really imagine suing Oracle for anything and their contracts seem more like customer chains. Still I think a lot of people read a lot into a suit and just because we are open source hackers doesn't mean we can't look good too :).
I never think of an entity to sue behind apache, but that is largely an accepted webserver by corporate types although I never paid much attention to the Apache model or the face of apache so maybe there is something behind that.
#7.1 Regina on 2008-05-05 22:20
And we have to add that MySQL is vastly easier to program than PostgreSQL. Just try to write a procedure that returns a result set in PostgreSQL.
The weird distinction between PostgreSQL and PlSQL means programming PostgreSQL requires more skills.
For most applications MySQL is good enough. And easier to program.
Note that I myself prefer PostgreSQL, but would hardly ever recommend it to a customer.
#8 Berend de Boer on 2008-05-06 18:11
I would agree that for most applications MySQL is good enough, but not necessarily easier to program. I too have recommended it over PostgreSQL for other reasons - e.g. it was an application that they needed well supported by many ISPs, they already had a MySQL server and were comfortable with it and they weren't doing anything complicated. But NEVER because it was easier to program.
The easier to program is I think more a perception than reality. If you are doing something trivial it will be trivial in either. Just because people tend to do simpler things in MySQL doesn't make it easier to program.
If you look at even Monty's criticisms of MySQL http://www.scribd.com/doc/2575733/The-future-of-MySQL-The-Project on slide 12. You can not use set returning stored procs of MySQL in the from clause which I find to be a huge disadvantage for most of the applications we write and makes many SQL Server to MySQL job ports painful. For simple set returning functions - nothing is easier than a PostgreSQL SQL set returning function. The MySQL PL is NOT easier.
I have had really bad experiences in MySQL where I wrote a marginally complicated View for one 5..release. something version and in a minor point newer release the view just didn't work at all. The same view works perfectly in SQL Server and PostgreSQL with no change. For MySQL prior to 5 - I even refused to work on many such jobs or charged a 20% premium because I can't imagine living without views for a marginally complex project.
#8.1 Regina on 2008-05-07 02:31
I think a big part of the issue is support. I can google MySQL and find more sites and problem resoultions and work arounds than I can count. Attempting to do the same thing with PostgreSQL, a developer and DBA finds themselves with limited resources. Even looking for books locally, there is amuch smaller selection and therefore less support.
#9 Jeff Crumbley on 2008-06-10 17:30
Syndicate This Blog
Show tagged entries