Slashdot Mirror


PostgreSQL vs. SAP?

Johann asks: "As my friend and I embark on building a large web site using open source development tools, I planned on using PostgreSQL. I was reminded that another 'enterprize' database is now released under the GPL - SAP DB. Since there have been countless Pg vs. MySQL comparisons on Slashdot, I wanted to ask: how does SAP DB compare technically to Pg?"

4 of 97 comments (clear)

  1. Marketing 101 by Anonymous Coward · · Score: 5, Insightful

    I know you seem pretty sure that you want one of those two (Postgres or SAP), but I don't think you should discount MySQL.

    Introduction of a third option. Makes the audience feel powerful and privileged.

    MySQL is considered (even by its detractors...and there are a lot of them!) to be much faster than the competition.

    In this world of benchmarks, is there any need to talk about one database being "considered" faster than any others? Sneaky.

    While other RDBMS makers go on about "tradeoffs,"

    Well, the "tradeoffs" that they were going on about were little unimportant things like transactions which, up until recently, MySQL didn't support.

    the MySQL team has put their money where their mouths are and delivered a database that makes speed the top priority.

    Use of language to suggest the MySQL boys are a bunch of good stand-up guys all around.

    This is vital in the enterprise.

    According to...? Sneaky.

    Furthermore, the latest MySQL releases have full support for transactions and complete ACID compliance.

    Once again, only a very recent phenomenon.

    MySQL also supports a greater and more useful subset of the SQL99 standard than either Postrgres or SAP.

    "More useful"? According to...? Sneaky.

    I am by no means a MySQL zealot (though there are plenty who are, and you won't have to look far to find them)

    Ah yes. This person is an everyman. A reasonable person. You can tell because he talks about the marginalized whackos and does not identify with them.

    Just ignore the fact that he's promoting the same software the marginalized whackos would.

    but I do think you should take all the options into account.
    And Slashdot uses MySQL. Could you even ask for a more shining recommendation?


    Appeal to Authority. Sneaky...

  2. Re:have you considered MySQL? by mosch · · Score: 4, Insightful
    MySQL is great. As long as you don't want stored procedures. Or triggers. Or sub-selects. Or row locking. Or check constraints. Or views. Or inherited tables. Or performance that doesn't disappear as soon as you have a moderately complex database structure.

    Yes, you can now have transactions and foreign keys, but to get them you'll be using InnoDB tables, which don't offer up any significant speed advantage. They run at slightly slower than postgres speeds, in my testing.

    MySQL sounds really good, especially if you haven't worked with real databases before, so you don't know what they're supposed to be able to do, but in the end it's not. Unfortunately, telling mysql advocates this is like convincing a Best Buy employee that overall PC performance cannot be compared by looking at the CPU clock rate.

  3. Re:Odd by Sxooter · · Score: 2, Insightful

    Just think of it. Postgresql crashes so seldomly (and even then, I've never seen it caused by anything but bad hardware ) that a problem that could show up during a crash took well over a year to show up.

    But let me ask the parent of the parent I'm responding to, how does MySQL recover from crashes? Does it have a write ahead log feature? does it use some other method to guarantee data integrity in case of database crash? I'm not being facetious, I don't use MySQL so I don't know.

    --

    --- It is not the things we do which we regret the most, but the things which we don't do.
  4. Re:have you considered MySQL? by jason_watkins · · Score: 3, Insightful

    MySQL is targeted at a particular feature set, and within that feature set, is fast as all heck.

    But it is not faster than Postgre or others in all circumstances, and is incredibly slower in many that bear importance to enterprise useage. MySQL provides responses with extremely low latency when there are few concurrent connections. This however, does not scale. It also tends to suffer under certain mixes of statements, or when using particular features.

    If you need what I would tend call a "more safe flat file" MySQL is perfect. MySQL also is perfect for some other situations due to it's popularity.

    If you need a relational database, potentially large, and that sustains a high number of concurrent connections, PostgreSQL is probibly your best option. While I've not tested the latest flavors of MySQL and Postgre, at the time I did do a comparision, even in 90% simple read queries MySQL's throughput fell below Postgre's after around 10 concurrent connections were reached.

    Look, I'm not a Postgre zealot either, but I do feel that many MySQL supports are not familiar with the rest of the database world, that MySQL is all they know, and they try and pull it out as a silver bullet answer to ever problem.

    And as others have pointed out, Slashdot is a poor example, they've written a great deal if middleware to deal with MySQL. If writing middleware is something you wanna do, go for it.

    The biggest criticism I could level at PostgreSQL is that replication isn't fully implimented yet. This really holds it back from scaling out, again, something important for the enterprise today.