Slashdot Mirror


Top 5 Reasons People Dismiss PostgreSQL

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."

7 of 704 comments (clear)

  1. The name by smittyoneeach · · Score: 4, Interesting

    "Postgre" is three times as long as "My".

    Then again, the P in LAMP has always been about the scripting language, not the database.

    MySQL and PHP have been quite the dynamic duo of the internet.

    That, and PostgreSQL took longer to have a native Lose32 port.

    The fact that you can bring Python right into PostgreSQL for good stored procedure justice seems to go unnoticed.

    --
    Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
  2. Web developers... by schon · · Score: 5, Interesting

    I think first and foremost is that is web developers who don't understand SQL, and so go about happily re-inventing its functionality in their web apps.

    99% of the problems that web developers face have already been solved for them, but they think that SQL is just a data dump, and thus see no reason to use Postgres, because they think that MySQL does everything they need. In reality, their apps would be faster to write and easier to maintain if they used SQL features.

    It's kind of like perl-syndrome, but on a larger scale.

    1. Re:Web developers... by schon · · Score: 4, Interesting

      perl-syndrome is the nasty habit that perl programmers get into (some might call it a mild case of brain damage), wherein when presented with a problem, say "oh, that's easy - it will only take me 10 minutes to whip up a perl script" rather than using an existing tool that does the same thing, easier, with much less hassle and opportunity for error.

      An example:

      Newbie-admin asks "how do you make your syslog files go to a different machine?"

      Perl-syndrome admin says "oh, that's easy - just write a quick perl script to tail the log files you want, then open a TCP connection to a perl script on the remote machine to write the data. I could write that in 15 minutes!"

      Experienced-admin says "Why don't you just configure syslog to send the files to the remote machine? It takes all of 5 seconds."

      perl-syndrome admin "TMTOWTDI!"

      (and yes, this exchange *really* happened, but it's not the only one - I've seen lots of other examples of guys with perl-syndrome posting perl scripts that could be done much easier with things like sed and awk.)

  3. Nobody's heard of it by Dlugar · · Score: 4, Interesting

    The biggest reason I've found personally why people don't use postgres is because they've never heard of it. Everybody and their dog has heard of mysql, but I've never found somebody who knows about postgres who isn't actually using it. mysql, for whatever reason, just has better marketing.

    Why that is I'm not entirely sure, since ever since I discovered postgres, mysql has been relegated to the role of "use-only-when-a-stupid-web-app-can't-use-anything -else". If I want a toy database, I'll use sqlite. If I want a real database, I'll use postgres. There really isn't much room in between the two.

    Dlugar

    --
    Computer Go: Writing Software to Play the Ancient Game of Go
  4. Interesting article, but not the reasons I hear by dskoll · · Score: 5, Interesting

    I don't hear those reasons when people dismiss PostgreSQL. The ones I hear are:

    • VACUUM is a pain. It's true that VACUUM is annoying, but later releases (especially 8.0 and 8.1) make VACUUM much more tolerable; we have customers whose databases are busy 24/7, and although the load does go up during a VACUUM, the database is still perfectly usable.
    • PostgreSQL is slow. That was true, but the 8.x series has improved performance dramatically.
    • PostgreSQL is hard to install and administer. Really, I think this is a matter of taste. If you are used to MySQL, then yes, there is a learning curve. OTOH, I'm used to PostgreSQL and find myself having to learn MySQL, and MySQL feels just as weird and unintuitive to me as PostgreSQL might to a long-time PostgreSQL user.
  5. No newbie guides by kyndig · · Score: 4, Interesting

    When I started programming a website, I knew I needed a database. I also knew absolutely nothing about php, sql, or even what they stood for. I was using a Perl based hacked link farm that used a flat-text database storage. Someone then pointed me to a php link farm that used MySQL. The installation text that came with the app was so easy to follow for a newbie, I had the link farm up and running in no time. I went to Books-A-Million a few weeks later, and found many books on PHP, MySQL, php/mysql - and nothing on PostgreSQL. When I finally did read up on RDBMS, found out that PostgreSQL did some functionality that MySQL didn't (at the time); I already had most of my site designed in php/mysql. I looked more into sub-queries in PostgreSQL, but the community structure was so scattered and non-newbie friendly, I decided to stick it out with MySQL (and havn't regretted it once). So my reasons for preference have nothing to do with wanting a windows version, different language, or other such assumption. Instead, my reasons are:
          * as everyone says, the name is catchy: MySQL
          * when I first was introduced to it, and to this day, Michael 'Monty' Widenius takes a personal interest in his work, and is a real down to earth guy ( had the pleasure of emailing him once) [you can probably still see him posting on the mysql dev lists these days..though I havn't followed it in a couple of years]
          * Extensive script language support for web development
          * Books for newbs and professionals (many books)
          * I like their website more..always have

    My shallow reasons..

    --
    My Thoughts, Kyndig
  6. Re:Reason number 6 by dj-nix · · Score: 5, Interesting

    Well, thats funny, because I also have had to write VoIP billing software, and am currently writing IP traffic rating and billing software. When I first started this type of business 5 years ago it was with MySQL, but I was frequently both crashing MySQL and getting junk data in my tables (The biggest problem being invalid dates!) When I started searching for a better option I tried a number of databases including FireBird and Postgresql but settled on Postgresql for 4 major reasons. 1) It has absolutely brilliant Date and Time handling, better even than Oracle. 2) It has native INET support which allows easy manipulation, sorting and searching of IP addresses. 3) It has SUB SELECT support which allowed me to reduce my application code a lot, by making the DB do the work (Always a good tradeoff in my opinion) 4) It has VIEW support which allowed me to generate some "simple" views of the data including some summaries which allowed the management to play to their hearts content with MS Access (As a frontend to PG) without having to understand the "real" data layout.
    Of course since then I have discovered many more things to love about Postgresql, including triggers and stored procedures etc (To be fair, MySQL has some of these features now, but did not at that time)
    Just to be clear my first Postgresql app handled ~5 million VoIP records per day on a single CPU, single disk desktop class machine and the only time I have EVER had Postgresql crash was due to a bad ram chip in server! Conversely, I can't count the number of time I and my customers have lost data with MySQL.