Slashdot Mirror

← Back to Stories (view on slashdot.org)

Top 5 Reasons People Dismiss PostgreSQL

Posted by ryuzaki0 on from the dispell-rank-2006 dept.

Jane Walker writes "In an effort to dispel some of the FUD surrounding this impressive product, this article puts forth several of the most commonplace reasons for a user to dismiss PostgreSQL." From the article: "While PostgreSQL's adoption rate continues to accelerate, some folks wonder why that rate isn't even steeper given its impressive array of features. One can speculate that many of the reasons for not considering its adoption tend to be based on either outdated or misinformed sources."

8 of 704 comments (clear)

  1. Availability by Anonymous Coward · · Score: 5, Insightful

    MySQL is pre-installed by most webhosts, and does the job for most tasks.

    First post?

    1. Re:Availability by NutscrapeSucks · · Score: 5, Insightful

      I know MS Access, Access came with Office, Access is fast and easy, and Access does all the things that I need a database to do...

      (Only partially being sarcastic here. Access is fine for a lot of things. It's just the mentality that kills me. LAMP Developers are the true heir to the VB/Access Guy Mentality)

      --
      Whenever I hear the word 'Innovation', I reach for my pistol.
  2. Other things... by Saeed+al-Sahaf · · Score: 5, Insightful

    Indeed. And once most people are familure with MySQL and the various tools and language support, there tends to be little reason to switch. PostgreSQL is a better database product, but many (all?) of the features that it's cheering section continue to tell us all about whenever the issue comes up, are simply not ones that the majority of MySQL users want or need. Maybe PostgreSQL fans should target Oracle usres.

    --
    "Who are in control, they are not in control of anything - they don't even control themselves!" - Glen Beck
    1. Re:Other things... by jadavis · · Score: 5, Insightful

      What about consistency? I talk to people all the time who are befuddled by MySQL's lax type checking. I know it's been hashed out before on /., but February 31st is NOT a date, and does not belong in any column named "date".

      If your application has an bug and inserts an invalid date, you don't want that error to cascade to another application (or another part in your application) and cause more errors down the line. By the time you detect the bug, it could be almost impossible to determine the source of the bug.

      Putting consistency checking in application A doesn't prevent application B from inserting invalid data. And when application A reports an error (due to it's wonderful in-application consistency checking), now you don't know what caused the error. It's long past the time that you can get meaningful state information from application B, at most you have database auditing tools that tell you "application B did it", but that's more easily implemented in PostgreSQL as well (triggers).

      And I'm not talking about super-advanced users only. I am talking about everyone who wants to catch the error early when they have the most possible information. Everyone who's just a programmer who wants to be able to trust that data from the database comes in a meaningful form. Everyone that just wants the database to do either what they expect, or throw an error.

      --
      Social scientists are inspired by theories; scientists are humbled by facts.
    2. Re:Other things... by jadavis · · Score: 5, Insightful

      Excellent point. That breaks isolation, and a bug in one application can still cascade problems into other applications.

      In particular this is likely to allow security problems in the application to cause malformed data to be entered into the database, thereby affecting other applications.

      --
      Social scientists are inspired by theories; scientists are humbled by facts.
  3. #1 Reason by __aanonl8035 · · Score: 5, Insightful

    It has to do with mindshare and previous history. Way back in the day... 1997, postgres was difficult to setup for some people. It was not the default choice included in many setups at ISPs. If you wanted to have an interactive web application at an ISP, on a unix machine, the most common option was MySQL. (On a windows machine it would be an ODBC connection to an access database, or a MS SQL server) Once something has achieved a significant mindshare and some momentum it is difficult to overcome. (But not impossible, especially if you do a better job, just takes time)

  4. Re:Or this? by rtaylor · · Score: 5, Insightful

    Do you really only have one user using the database at any given time? If you do only have one user, speed probably doesn't matter at all.

    Benchmarks like that should be run with a couple of hundred active users all doing different things (mix of updates, insert, deletes, and selects) -- a real world use-case.

    You will quickly find that scores change.

    We had a MySQL versus PostgreSQL battle once. The MySQL people put together a benchmark showing MySQL was nearly 10 times faster. The benchmark was a single user going through the steps.

    We then took the exact same thing and put Apache in front and benchmarked with 5 active users -- now they were about even. At 10 users PostgreSQL was about 5x faster. At 100 users MySQL was unable to finish the test. PostgreSQL was serving each of the 100 users at a rate comparable to how it dealt with 10 active users.

    Benchmarks for benchmark sake is useless. Benchmarks that model your actual use case are quite valuable.

    --
    Rod Taylor
  5. Comment removed by account_deleted · · Score: 5, Insightful

    Comment removed based on user account deletion