Thread: 12 Silver Bullets
Anyone ever put together something I call a Silver Bullet list that showcases the top 12 features in PostgreSQL that could kill MySQL?
Care to contribute? Any advice?
Bob Zurek
On Tue, Aug 14, 2007 at 05:35:59PM -0400, Bob Zurek wrote: > Anyone ever put together something I call a Silver Bullet list that > showcases the top 12 features in PostgreSQL that could kill MySQL? > > Care to contribute? Any advice? We need to be careful on this... a few years ago it was easy to bash MySQL on a feature-comparison basis. They got tired of that and have been working to "check off the boxes" on a feature comparison chart. Now, many of these features are pretty incomplete, and many of them have non-trivial flaws/gotchas... but it's much harder to present those things in a way that makes a persuasive case. In case you haven't already, you should google: mysql gotchas. -- Decibel!, aka Jim Nasby decibel@decibel.org EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
Attachment
Bob, > Anyone ever put together something I call a Silver Bullet list that > showcases the top 12 features in PostgreSQL that could kill MySQL? > > Care to contribute? Any advice? Have you read the discussion and wiki pages around PostgreSQL vs. MySQL? Also, quite frankly, I'm thinking that I'd rather target the DBs with money (Oracle, DB2, MSSQL). -- --Josh Josh Berkus PostgreSQL @ Sun San Francisco
On Tue, 14 Aug 2007, Josh Berkus wrote: > Also, quite frankly, I'm thinking that I'd rather target the DBs with money > (Oracle, DB2, MSSQL). I started with MySQL because it was obvious how to make a fairly tight case against using it, and because so many of the comparisons out there were just grossly wrong and/or outdated. The comparisions involving PostgreSQL vs. Oracle/DB2/MSSQL that are floating around the web already seemed relatively fair in most cases. The biggest problem I forsee with targeting the "with money" crowd is how to cope with the benchmarking aspect. You/Sun handed me a great pair to address PG vs. MySQL performance and I had the tweakers.net one to point to as well, doing similar comparisions against the commercial databases has messy bits like non-disclosure restrictions involved. Anyway, as I'd kinda hoped would happen, the information that's come out of the tail of the MySQL discussion (like the MVCC and rollback details) leads right into mounting a campaign against the bigger guns. I considered it more of a warm-up than a final target. I think the replication area really need to be addressed better before starting that fight as well. -- * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
On 8/14/07, Josh Berkus <josh@agliodbs.com> wrote: > Also, quite frankly, I'm thinking that I'd rather target the DBs with money > (Oracle, DB2, MSSQL). Agreed. -- Jonah H. Harris, Software Architect | phone: 732.331.1324 EnterpriseDB Corporation | fax: 732.331.1301 33 Wood Ave S, 3rd Floor | jharris@enterprisedb.com Iselin, New Jersey 08830 | http://www.enterprisedb.com/
On Tue, 2007-08-14 at 17:35 -0400, Bob Zurek wrote: > Anyone ever put together something I call a Silver Bullet list that > showcases the top 12 features in PostgreSQL that could kill MySQL? > > Care to contribute? Any advice? Hi Bob, For me, PostgreSQL and MySQL have different use cases. - MySQL's feature set corresponds to a large proportion of web apps: mostly read-only, simple SQL, design implemented by developers, so no DBA required. - PostgreSQL's feature set works for "difficult/complex" web apps. Each does its job well in that space and is in no danger of forcing the other one from its niche. MySQL doesn't seem like it will ever say that, but thats fine because it results in a steady stream of ex-MySQL users happy to testify to its abilities and inabilities. PostgreSQL to MySQL is like SQLServer is to Access. Microsoft publish warnings about data loss with Access, but there's still more people running it in production than Oracle or SQLServer. The idea that one size fits all isn't true, so in my opinion the category of "Open Source Databases" is about as useful a distinction for decision-makers as "West Coast Databases" would be. It's not a single market segment that we all compete in, there are multiple market segments/use cases. BTW, MySQL isn't even "The World's Most Popular Open Source Database", if we judge that on installed systems: BerkeleyDB is. MySQL markets to lots of people, in my opinion mostly younger developers, but those people are not the people that run large businesses or manage large production databases. Developers tend to have much less say in database decisions when the database contains high visibility, high value data. That's when architects and DBAs get involved and its typically a no-contest in favour of PostgreSQL, pick any 12 features. The new Async Commit feature in PostgreSQL 8.3 might be considered to be a "MySQL Killer", since it offers relaxed durability guarantees in return for increased performance, an option which we know that many MySQL users happily choose (until it crashes). The Async Commit feature allows synchronous and asynchronous commits to co-exist, which is not possible with MySQL or Solid. EDB sponsored this feature, allowing PostgreSQL to address a wider range of sensing/monitoring applications such as RFID tag tracking or number plate recognition/traffic systems, rather than simply attacking MySQL. http://developer.postgresql.org/pgdocs/postgres/wal-async-commit.html -- Simon Riggs EnterpriseDB http://www.enterprisedb.com
Agree..but doesn't it make sense to start with what is perceived as the head to head competitor in the open source space first? Bob -----Original Message----- From: Josh Berkus [mailto:josh@agliodbs.com] Sent: Tuesday, August 14, 2007 7:48 PM To: pgsql-advocacy@postgresql.org Cc: Bob Zurek Subject: Re: [pgsql-advocacy] 12 Silver Bullets Bob, > Anyone ever put together something I call a Silver Bullet list that > showcases the top 12 features in PostgreSQL that could kill MySQL? > > Care to contribute? Any advice? Have you read the discussion and wiki pages around PostgreSQL vs. MySQL? Also, quite frankly, I'm thinking that I'd rather target the DBs with money (Oracle, DB2, MSSQL). -- --Josh Josh Berkus PostgreSQL @ Sun San Francisco
On August 15, 2007 08:17 am, Bob Zurek wrote: > Agree..but doesn't it make sense to start with what is perceived as the > head to head competitor in the open source space first? No it does not, that is like asking Porsche to go head to head with Yugo. Just because the 2 are on the same price point does not mean they are in the same class. And I agree while having some sort of comparison sheet that says why pg over mysql, we should have the same for the real DB's in our class. > > Bob > > -----Original Message----- > From: Josh Berkus [mailto:josh@agliodbs.com] > Sent: Tuesday, August 14, 2007 7:48 PM > To: pgsql-advocacy@postgresql.org > Cc: Bob Zurek > Subject: Re: [pgsql-advocacy] 12 Silver Bullets > > Bob, > > > Anyone ever put together something I call a Silver Bullet list that > > showcases the top 12 features in PostgreSQL that could kill MySQL? > > > > Care to contribute? Any advice? > > Have you read the discussion and wiki pages around PostgreSQL vs. MySQL? > > Also, quite frankly, I'm thinking that I'd rather target the DBs with > money > (Oracle, DB2, MSSQL). -- Darcy Buskermolen Command Prompt, Inc. +1.503.667.4564 X 102 http://www.commandprompt.com/ PostgreSQL solutions since 1997
Bob, > Agree..but doesn't it make sense to start with what is perceived as the > head to head competitor in the open source space first? Well, we want to have a story about how PostgreSQL compares to MySQL, but ultimately it's not the market we or EDB wants. MySQL has a less than 3% conversion rate of turning their users into paying customers; MySQL AB is having enough trouble capitalizing their userbase, and the idea that we could do better is fanciful. Also, a preoccupation with MySQL in our literature would indicated to readers that *we* are obsessed with them as a competitor and could actually end up boosting their image (like the famous Windows vs. Linux campaign). So any MySQL-competitive rhetoric should be strictly defensive and low-key. Besides, MySQL is on the side of open source databases and when push comes to shove we'll side with them against Oracle/Microsoft/IBM. We collaborate with them on activites of joint concern, like PDO and OSS benchmarks, and steal feature ideas from each other. Many of us in the community know the MySQL developers personally and one PostgreSQL community member even works for MySQL AB. So we're not out to "get" them. It's a friendly rivalry. Or to put it another way: what do you want, Oracle & MS's $billions or MySQL's $50m? I know what I want ... -- Josh Berkus PostgreSQL @ Sun San Francisco
On Tue, 14 Aug 2007, Bob Zurek wrote: > Anyone ever put together something I call a Silver Bullet list that > showcases the top 12 features in PostgreSQL that could kill MySQL? I'm not sure if it's exactly the same list you're looking for, because many of these are more differences in priorities rather than features, but here's my list of the top 12 reasons why I use PostgreSQL instead of MySQL after my recent re-examination of this topic: 1. One database engine, completely integrated into core 2. Robust transactional ACID behavior under all circumstances 3. BSD License makes it unambiguously open-source 4. Aims for as close to SQL:2003 compliance as feasible 5. Developers fanatical about code quality, correctness, and testing 6. Undefined or unsupported operations never fail silently 7. MVCC always gives consistent view of your data 8. Complicated joins handled as automatically as possible 9. Designed to scale to large numbers of simultaneous read and write users 10. Transactional DDL allows safe schema changes 11. Multitude of mature server-side programming options 12. Fantastic community support ranging from users to the core team This is of course now the content that's on the Wiki in the PG vs. MySQL page if anyone wants to play with this list over there instead of via this mailing list. I've pushed the "Transactional DDL" material that was there for a bit into a new page on techdocs which should be published shortly, and all of the feedback and corrections to the original PG vs. MySQL page (like the innodb tunables and the 8.1/8.2 ambiguity) have now been incorporated. Once all the pages make their way through techdocs, I know I'm feeling pretty done with beating on MySQL. -- * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
On Thu, 2007-08-16 at 00:22 -0400, Greg Smith wrote: > 2. Robust transactional ACID behavior under all circumstances Async commit changes that, since it relaxes the Durability aspect. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com
On Thu, 16 Aug 2007, Simon Riggs wrote: >> 2. Robust transactional ACID behavior under all circumstances > Async commit changes that, since it relaxes the Durability aspect. And one can wreak havoc right now if you turn fsync off. Maybe the wording may need to be tweaked here. The disclaimer in the detailed document is "barring hardware failure or grossly improper configuration". If you expected ACID, but used Async commit, that certainly falls into the improper configuration category. -- * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
> On Thu, 16 Aug 2007, Simon Riggs wrote: > >>> 2. Robust transactional ACID behavior under all circumstances >> Async commit changes that, since it relaxes the Durability aspect. > > And one can wreak havoc right now if you turn fsync off. Maybe the > wording may need to be tweaked here. The disclaimer in the detailed > document is "barring hardware failure or grossly improper configuration". > If you expected ACID, but used Async commit, that certainly falls into the > improper configuration category. > Does the reader really need to know so many details in a list like this? PgSQL defaults to ACID, which is the point I'd like to make in a list like this; the user does not have to do anything special to get ACID, unlike some databases who shall rename nameless... Sure a user can force non-acid behaviour, that's not what you want to put forward when promoting PgSQL. It's the truth, but it's too much information.
On Thursday 16 August 2007 03:46, vincent wrote:
> > On Thu, 16 Aug 2007, Simon Riggs wrote:
> >>> 2. Robust transactional ACID behavior under all circumstances
> >>
> >> Async commit changes that, since it relaxes the Durability aspect.
> >
> > And one can wreak havoc right now if you turn fsync off. Maybe the
> > wording may need to be tweaked here. The disclaimer in the detailed
> > document is "barring hardware failure or grossly improper configuration".
> > If you expected ACID, but used Async commit, that certainly falls into
> > the improper configuration category.
>
> Does the reader really need to know so many details in a list like this?
>
> PgSQL defaults to ACID, which is the point I'd like to make in a list like
> this; the user does not have to do anything special to get ACID, unlike
> some databases who shall rename nameless...
>
The windows default table type for mysql is innodb, which is ACID. Since > 50%
of thier users work on windows (perhaps not deploy, but do
development/testing) this means that most of them are getting ACID out of the
box as well.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
Terrific. Now this is what I was looking for...a starting point along
with validation. Sorry if I wasn't clear enough in the first email.
Thanks Greg for taking the first crack and others for this feedback.
Z.
-----Original Message-----
From: pgsql-advocacy-owner@postgresql.org
[mailto:pgsql-advocacy-owner@postgresql.org] On Behalf Of vincent
Sent: Thursday, August 16, 2007 3:46 AM
To: pgsql-advocacy@postgresql.org
Subject: Re: [pgsql-advocacy] 12 Silver Bullets
> On Thu, 16 Aug 2007, Simon Riggs wrote:
>
>>> 2. Robust transactional ACID behavior under all circumstances
>> Async commit changes that, since it relaxes the Durability aspect.
>
> And one can wreak havoc right now if you turn fsync off. Maybe the
> wording may need to be tweaked here. The disclaimer in the detailed
> document is "barring hardware failure or grossly improper
configuration".
> If you expected ACID, but used Async commit, that certainly falls into
the
> improper configuration category.
>
Does the reader really need to know so many details in a list like this?
PgSQL defaults to ACID, which is the point I'd like to make in a list
like
this; the user does not have to do anything special to get ACID, unlike
some databases who shall rename nameless...
Sure a user can force non-acid behaviour, that's not what you want to
put
forward when promoting PgSQL. It's the truth, but it's too much
information.
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
On Thu, Aug 16, 2007 at 11:47:12AM -0400, Robert Treat wrote: > On Thursday 16 August 2007 03:46, vincent wrote: > > > On Thu, 16 Aug 2007, Simon Riggs wrote: > > >>> 2. Robust transactional ACID behavior under all circumstances > > >> > > >> Async commit changes that, since it relaxes the Durability aspect. > > > > > > And one can wreak havoc right now if you turn fsync off. Maybe the > > > wording may need to be tweaked here. The disclaimer in the detailed > > > document is "barring hardware failure or grossly improper configuration". > > > If you expected ACID, but used Async commit, that certainly falls into > > > the improper configuration category. > > > > Does the reader really need to know so many details in a list like this? > > > > PgSQL defaults to ACID, which is the point I'd like to make in a list like > > this; the user does not have to do anything special to get ACID, unlike > > some databases who shall rename nameless... > > > > The windows default table type for mysql is innodb, which is ACID. Since > 50% > of thier users work on windows (perhaps not deploy, but do > development/testing) this means that most of them are getting ACID out of the > box as well. What about the catalogs? ACID user tables don't do much good if your catalog is hosed after a crash... -- Decibel!, aka Jim Nasby decibel@decibel.org EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
Attachment
On Thu, 2007-08-16 at 06:15 +0100, Simon Riggs wrote:
> On Thu, 2007-08-16 at 00:22 -0400, Greg Smith wrote:
>
> > 2. Robust transactional ACID behavior under all circumstances
>
> Async commit changes that, since it relaxes the Durability aspect.
>
fsync, too.
I think there are some important differences between PostgreSQL having a
few options which can trade away data safety, and what MySQL does.
1. PostgreSQL is about as safe as you can get with default options.
2. In PostgreSQL, all features are available and all semantic behaviors
are consistent in the safest mode of operation.
Neither of these things are true with MySQL.
Regards,
Jeff Davis
On Thu, Aug 16, 2007 at 11:47:12AM -0400, Robert Treat wrote: > On Thursday 16 August 2007 03:46, vincent wrote: > > > On Thu, 16 Aug 2007, Simon Riggs wrote: > > >>> 2. Robust transactional ACID behavior under all circumstances > > >> > > >> Async commit changes that, since it relaxes the Durability > > >> aspect. > > > > > > And one can wreak havoc right now if you turn fsync off. Maybe > > > the wording may need to be tweaked here. The disclaimer in the > > > detailed document is "barring hardware failure or grossly > > > improper configuration". If you expected ACID, but used Async > > > commit, that certainly falls into the improper configuration > > > category. > > > > Does the reader really need to know so many details in a list like > > this? > > > > PgSQL defaults to ACID, which is the point I'd like to make in a > > list like this; the user does not have to do anything special to > > get ACID, unlike some databases who shall rename nameless... > > The windows default table type for mysql is innodb, which is ACID. > Since > 50% of thier users work on windows (perhaps not deploy, but > do development/testing) this means that most of them are getting > ACID out of the box as well. Until they move to production on Linux, *BSD or Solaris, at which point all the stuff that worked on the development boxes starts breaking--silently, as characterizes MySQL--on prod boxes. This qualifies, not as a "feature," but as a really severe gotcha. Cheers, David. -- David Fetter <david@fetter.org> http://fetter.org/ phone: +1 415 235 3778 AIM: dfetter666 Skype: davidfetter Remember to vote! Consider donating to PostgreSQL: http://www.postgresql.org/about/donate
>> PgSQL defaults to ACID, which is the point I'd like to make in a list >> like >> this; the user does not have to do anything special to get ACID, unlike >> some databases who shall rename nameless... >> > > The windows default table type for mysql is innodb, which is ACID. Since > > 50% > of thier users work on windows (perhaps not deploy, but do > development/testing) this means that most of them are getting ACID out of > the > box as well. True, but that is also exactly my point. Wether they get ACID behaviour depends on their platform, version and whatnot (phmyadmin for example doesn't always play nice) In PostgreSQL it doesn't matter where you develop or install, nor what tool you use. Every CREATE TABLE will result in an ACID compliant table. That sounds like a bonus to me :)
On Thursday 16. August 2007, David Fetter wrote: >On Thu, Aug 16, 2007 at 11:47:12AM -0400, Robert Treat wrote: >> The windows default table type for mysql is innodb, which is ACID. >> Since > 50% of thier users work on windows (perhaps not deploy, but >> do development/testing) this means that most of them are getting >> ACID out of the box as well. > >Until they move to production on Linux, *BSD or Solaris, at which >point all the stuff that worked on the development boxes starts >breaking--silently, as characterizes MySQL--on prod boxes. > >This qualifies, not as a "feature," but as a really severe gotcha. Right. Most web hotels that offer MySQL only support MyISAM tables. Guess what happens if you try to create a table of type InnoDB in a database that only has MyISAM installed?, Yeah, it silently creates an 'ACID-free' MyISAM table. http://sql-info.de/en/mysql/database-definition.html#2_4 -- Leif Biberg Kristensen | Registered Linux User #338009 http://solumslekt.org/ | Cruising with Gentoo/KDE My Jazz Jukebox: http://www.last.fm/user/leifbk/
Simon Riggs wrote: > > - MySQL's feature set corresponds to ...: > mostly read-only, simple SQL, design implemented by developers, so no > DBA required. > > - PostgreSQL's feature set works for "difficult/complex" web apps. Really. It looks to me like MySQL's niche that postgresql doesn't yet touch is in the most complex, most insert/update intensive applications. The two reference MySQL projects that first come to my mind are the Sabre airline system[1]; and Google Adwords[2,3]. Both extremely update intensive applications - far beyond what I see PostgreSQL being used for. In contrast - I see postgresql's successes mostly in simple (single monolithic instances) and read-mostly applications (data mining like Genentech's case study on the web site). While I totally agree with Josh that Oracle's $7.2Billion database revenue [4] is way more interesting than MySQL's $0.05Billion; it seems a bit odd to see people suggesting that MySQL is for simpler and read-mostly systems; when it seems the most complex and most update intensive applications are the niche that it has that PostgreSQL doesn't yet. What am I missing? [1] http://h71028.www7.hp.com/enterprise/downloads/Sabre-HP-MySQL-case-study.pdf [2] http://xooglers.blogspot.com/2005/12/lets-get-real-database.html [3] http://zurlocker.typepad.com/theopenforce/2005/12/googles_use_of_.html [4] http://www.sqlmanager.net/en/news/sql/1189
Ron Mayer wrote: > Simon Riggs wrote: > > > > - MySQL's feature set corresponds to ...: > > mostly read-only, simple SQL, design implemented by developers, so no > > DBA required. > > > > - PostgreSQL's feature set works for "difficult/complex" web apps. > > Really. It looks to me like MySQL's niche that postgresql doesn't yet > touch is in the most complex, most insert/update intensive applications. > > The two reference MySQL projects that first come to my mind are > the Sabre airline system[1]; and Google Adwords[2,3]. Both > extremely update intensive applications - far beyond what I see > PostgreSQL being used for. I think though the applications themselves are update-intensive, MySQL's role in the application is mostly as read-only web storage. There are other databases behind Sabre for sure that do the actual update load. Also, MySQL's 0.050B revenue isn't representitive of its installed base or growth as with the commercial companies. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Ron, Talk about spin... I just read the Sabre case study that you pointed out. It is interesting how they portray it because I sat in a case study at Gartner's Open Source Summit that was given by the guys at Travelocity. What the case study DOESN'T tell you is that NONE of the transactions run through MySQL. The entire backend for actual transactions runs on Oracle. When you go to Travelocity and do all your searches, that is pulling data from MySQL. The MySQL data is updated from Oracle back end databases. When you decide to purchase, the system then switches to Oracle where all the real work happens. MySQL is used for read-only work at Sabre. Derek M. Rodner Director, Product Strategy EnterpriseDB Corporation 732.331.1333 office 484.252.1943 cell www.enterprisedb.com -----Original Message----- From: pgsql-advocacy-owner@postgresql.org [mailto:pgsql-advocacy-owner@postgresql.org] On Behalf Of Ron Mayer Sent: Thursday, August 16, 2007 3:12 PM To: Simon Riggs; pgsql-advocacy@postgresql.org Subject: [pgsql-advocacy] Are we mischaracterising mysql? Re: 12 Silver Bullets Simon Riggs wrote: > > - MySQL's feature set corresponds to ...: > mostly read-only, simple SQL, design implemented by developers, so no > DBA required. > > - PostgreSQL's feature set works for "difficult/complex" web apps. Really. It looks to me like MySQL's niche that postgresql doesn't yet touch is in the most complex, most insert/update intensive applications. The two reference MySQL projects that first come to my mind are the Sabre airline system[1]; and Google Adwords[2,3]. Both extremely update intensive applications - far beyond what I see PostgreSQL being used for. In contrast - I see postgresql's successes mostly in simple (single monolithic instances) and read-mostly applications (data mining like Genentech's case study on the web site). While I totally agree with Josh that Oracle's $7.2Billion database revenue [4] is way more interesting than MySQL's $0.05Billion; it seems a bit odd to see people suggesting that MySQL is for simpler and read-mostly systems; when it seems the most complex and most update intensive applications are the niche that it has that PostgreSQL doesn't yet. What am I missing? [1] http://h71028.www7.hp.com/enterprise/downloads/Sabre-HP-MySQL-case-study .pdf [2] http://xooglers.blogspot.com/2005/12/lets-get-real-database.html [3] http://zurlocker.typepad.com/theopenforce/2005/12/googles_use_of_.html [4] http://www.sqlmanager.net/en/news/sql/1189 ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org
This is from a recent article in RegDeveloper where they even admit that they are not designed for enterprise applications... ================================ They use it for small applications, at the departmental level, for the newer web-based applications - in other words, in all sorts of innovative ways that are well suited to MySQL's particular strengths. But they are not yet using it for the "traditional" enterprise database application workloads. How can I be so sure of this? Because I'm quoting Steve Curry, the director of corporate communications at MySQL who really ought to know: "I think we'll all agree that MySQL is not a 'traditional' enterprise database - we never have been and aren't trying to suddenly become one now. "We don't compete head-to-head against Oracle, DB2, Teradata, etc. If users are looking to build that type of higher-end data warehouse/OLTP/client-server application, then they've probably selected one of the traditional vendors or one of the open-source alternatives that are trying to directly emulate them. That's just not us - we're carving out new, different ground that is not based on replacing existing applications but creating new complementary online ones." ================================= And the link: http://www.regdeveloper.co.uk/2007/03/18/mysql_enterprise_fit/ Derek M. Rodner Director, Product Strategy EnterpriseDB Corporation 732.331.1333 office 484.252.1943 cell www.enterprisedb.com -----Original Message----- From: pgsql-advocacy-owner@postgresql.org [mailto:pgsql-advocacy-owner@postgresql.org] On Behalf Of Derek Rodner Sent: Thursday, August 16, 2007 3:29 PM To: Ron Mayer; Simon Riggs; pgsql-advocacy@postgresql.org Subject: Re: [pgsql-advocacy] Are we mischaracterising mysql? Re: 12 Silver Bullets Ron, Talk about spin... I just read the Sabre case study that you pointed out. It is interesting how they portray it because I sat in a case study at Gartner's Open Source Summit that was given by the guys at Travelocity. What the case study DOESN'T tell you is that NONE of the transactions run through MySQL. The entire backend for actual transactions runs on Oracle. When you go to Travelocity and do all your searches, that is pulling data from MySQL. The MySQL data is updated from Oracle back end databases. When you decide to purchase, the system then switches to Oracle where all the real work happens. MySQL is used for read-only work at Sabre. Derek M. Rodner Director, Product Strategy EnterpriseDB Corporation 732.331.1333 office 484.252.1943 cell www.enterprisedb.com -----Original Message----- From: pgsql-advocacy-owner@postgresql.org [mailto:pgsql-advocacy-owner@postgresql.org] On Behalf Of Ron Mayer Sent: Thursday, August 16, 2007 3:12 PM To: Simon Riggs; pgsql-advocacy@postgresql.org Subject: [pgsql-advocacy] Are we mischaracterising mysql? Re: 12 Silver Bullets Simon Riggs wrote: > > - MySQL's feature set corresponds to ...: > mostly read-only, simple SQL, design implemented by developers, so no > DBA required. > > - PostgreSQL's feature set works for "difficult/complex" web apps. Really. It looks to me like MySQL's niche that postgresql doesn't yet touch is in the most complex, most insert/update intensive applications. The two reference MySQL projects that first come to my mind are the Sabre airline system[1]; and Google Adwords[2,3]. Both extremely update intensive applications - far beyond what I see PostgreSQL being used for. In contrast - I see postgresql's successes mostly in simple (single monolithic instances) and read-mostly applications (data mining like Genentech's case study on the web site). While I totally agree with Josh that Oracle's $7.2Billion database revenue [4] is way more interesting than MySQL's $0.05Billion; it seems a bit odd to see people suggesting that MySQL is for simpler and read-mostly systems; when it seems the most complex and most update intensive applications are the niche that it has that PostgreSQL doesn't yet. What am I missing? [1] http://h71028.www7.hp.com/enterprise/downloads/Sabre-HP-MySQL-case-study .pdf [2] http://xooglers.blogspot.com/2005/12/lets-get-real-database.html [3] http://zurlocker.typepad.com/theopenforce/2005/12/googles_use_of_.html [4] http://www.sqlmanager.net/en/news/sql/1189 ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
derek.rodner@enterprisedb.com ("Derek Rodner") writes:
> Ron,
>
> Talk about spin... I just read the Sabre case study that you pointed
> out. It is interesting how they portray it because I sat in a case
> study at Gartner's Open Source Summit that was given by the guys at
> Travelocity. What the case study DOESN'T tell you is that NONE of the
> transactions run through MySQL.
>
> The entire backend for actual transactions runs on Oracle. When you go
> to Travelocity and do all your searches, that is pulling data from
> MySQL. The MySQL data is updated from Oracle back end databases. When
> you decide to purchase, the system then switches to Oracle where all the
> real work happens. MySQL is used for read-only work at Sabre.
I was under the impression that IMS was still the primary database
system "of choice" for the high end OLTP work.
That was the case when I was there, and for that to have been dropped
would have required *much* louder trumpeting of change than I have
seen...
--
(reverse (concatenate 'string "moc.enworbbc" "@" "enworbbc"))
http://cbbrowne.com/info/multiplexor.html
"never post anything you don't want to see on your resume..."
-- Martin Minow <minow@pobox.com>
On Thu, 16 Aug 2007, Ron Mayer wrote: > It looks to me like MySQL's niche that postgresql doesn't yet > touch is in the most complex, most insert/update intensive applications. Dude, you need to cut back on your dose of marketing kool-aid; that stuff will kill you. Derek already gutted the Sabre study. Google's Adwords was a situation where they were willing to roll their own transactional support sufficient for their purposes on top of the shaky MySQL base, and that all took place a long time ago--back in those days, the version of PostgreSQL available at the time wouldn't have been a reasonable alternative. They're big enough now that they've just gone in and fixed[1] the stuff that was seriously wrong with MySQL since then to keep everything going. The fact that someone operating on the scale of Google can build an architecture and patch MySQL such that it works well for them is in no way proof that it's suitable for "the most complex, most insert/update intensive applications" for the rest of the business world. [1] http://code.google.com/p/google-mysql-tools/ -- * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD