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

10 of 97 comments (clear)

  1. have you considered MySQL? by tps12 · · Score: 0, Informative

    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.

    MySQL is considered (even by its detractors...and there are a lot of them!) to be much faster than the competition. While other RDBMS makers go on about "tradeoffs," the MySQL team has put their money where their mouths are and delivered a database that makes speed the top priority. This is vital in the enterprise.

    Furthermore, the latest MySQL releases have full support for transactions and complete ACID compliance. MySQL also supports a greater and more useful subset of the SQL99 standard than either Postrgres or SAP.

    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), 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?

    --

    Karma: Good (despite my invention of the Karma: sig)
  2. interface support by galore · · Score: 5, Informative

    one big thing to consider is the interface to the db you'll be using. i chose postgres for a large server-side java web-application, and while i have zero complaints about postgres the database, the jdbc postgres interface is a complete mess. if you're doing anything beyond the most basic operations, you'll find a _lot_ of the jdbc-2 spec completely or partially unimplimented (and these shortcomings are, of course, undocumented). i've put far too many hours pouring through jdbc driver code in the last year with postgres. though, i give the developers credit for making steady progress in the last year, it just isn't there yet.

    like you, i've been pondering the switch to SAP-DB - from looking through the source, their jdbc implementation seems to be very complete. the only problem i've run into with SAP is the lack of readable documentation... the manual seems to have lots of information, but it isn't exactly developer-friendly.

    if this is an "enterprise" level application, i see little choice but to dive into SAP and figure it all out - otherwise i think you'll run into bigger problems down the road.

    1. Re: interface support by nconway · · Score: 3, Informative
      I have also used the C++ interface, which seems to work O.K, but it is much less powerfull than the jdbc implementation could be if it were to implement some of the cool features such as writable result sets and prepared statements that the java interfaces declare (but which PostgreSQL doesn't yet implement)
      For the C++ interface, you might want to try libpqxx -- it's much nicer (IMHO) than the default libpq++. It's been integrated into the CVS tree and will be in the next release of PostgreSQL.

      Updateable result sets for JDBC have been implemented in CVS, and will be in 7.3. I implemented prepared statements and that should be in CVS soon, but I'm not sure what the status of JDBC support for that is.
      Downloading the latest PostgreSQL from cvs (a few months ago) did appear to include the source for this, however they wouldn't build with jdk1.4 due to many new methods having been added to the interfaces since the implementation was last updated (and even many of those that were there will just throw an org.postgresql.Driver.notImplemented exception).
      Hmmm... this will definately need to be fixed before the 7.3 release (if the 1.4 methods aren't implemented, they should at least be declared and throw exceptions so that JDBC will compile out of the box with JDK 1.4).
  3. hmmm.... by diesel_jackass · · Score: 3, Informative

    STORED PROCEDURES?

    You can't do everything in one line of SQL. Not in a timely fashion anyways. Aside from the speed of the database, you should also consider the speed of development.

  4. On stored proc by Betcour · · Score: 2, Informative

    Stored proc can be useful but you have to remember that :
    a) They are not portable at all. Moving to another database means rewriting all of them.
    b) They tend mix business logic and data which is a big no-no as far as three-tier architecture goes

    For these two reason I think everyone should restrict stored procedure to trivial repetitive things and keep the complex logic in a separate layer (outside the database that is)

  5. Re:anyone else notice the history of SAP by Leknor · · Score: 3, Informative

    The black bars are weird. If you use the Wayback Machine you can see what they obsure: http://web.archive.org/web/20011130142504/http://w ww.sapdb.org/history.htm

    The removed text is

    • Subsidiary of Software AG
    • Software AG quits R/3 DBMS market
    • ADABAS D
    • ADABAS D
    • ADABAS D

    I think a marketing drone just doesn't want to show any sign of weakness in the product's history.

  6. From using MySQL/PostgreSQL and researching SAP... by mikehoskins · · Score: 5, Informative

    I'm sorry that most of the responses haven't answered your question. I'll try to partially answer it, but I bet you already know all of this. I really like PostgreSQL and use it. If I were wanting to get a really big web site together, I'd try SAPDB, or just go with either DB/2 or Oracle.

    My info about SAPDB is research-based, as I did a lot of that. Please feel free to correct me, if I'm wrong, in any way. MySQL has steadily improved, so a couple of items, below may be out of date.

    I see that SAPDB is really an Oracle killer. It is a true enterprise-ready DB. If you want all the features of a big DB, such as replication, partitioning, etc., use SAPDB. You can get true commercial support, etc. Read their PDF's and be impressed.

    However, you might want to know why I chose PostgreSQL over MySQL and SAPDB:

    1.) PostgreSQL is really ACID compliant, as is SAPDB. MySQL, on the other hand hasn't yet proved itself in this area. Give MySQL a few more months, though, and we'll see, with version 4.1.

    2.) Hosting companies support MySQL really well, and PostgreSQL only partially well. I have yet to see SAPDB as a hosting offering. Oracle is rare, too, but expensive.

    3.) All three are free, in both senses of the word, while DB/2, Sybase, Oracle, etc., are not. (No preference in this area.)

    4.) There is an enormous userbase for MySQL, and a sizable one for PostgreSQL, so I can get help from peers 24 by 7. SAPDB, unfortunately, does not have much in this area.

    5.) PostgreSQL 7.1.x+ is supposed to scale better in many ways compared to MySQL 3.xx+. Many benchmarks seem to bear out the fact that PGSQL annihilates MySQL 3.xx, after about 5-10 or so web users. PGSQL seems to beat Oracle up through and beyond 100 simultaneous web users. I cannot find any benchmark on SAP, anywhere.

    6.) Installing PostgreSQL and MySQL are easy, easy, easy. It's not so easy with SAPDB. While I'm no neophyte, when you consider remote hosting issues, I hope to have a system I can quickly rebuild if hardware dies.

    7.) PostgreSQL has enough enterprise-ready features for my web site. MySQL did not (and probably still does not). SAPDB is almost overkill. Views, triggers, foreign keys, constraints of various kinds, stored procedures, versioning, hot backups, etc., are all available in PostgreSQL and SAPDB. One responder indicated that programming time is more important than benchmarks -- amen, preach it, brother. Your time programming and tweaking are far more expensive than hardware and most software.

    8.) After working with PostgreSQL and MySQL, I saw that care and feeding (DBA work, in particular) were very simplified, straight forward, and quick. SAPDB smacks of Oracle, in terms of tweaking, complexity, etc. (I was an Oracle DBA for two years; a RedBrick DBA; worked for Informix; and have administered MySQL, PostgreSQL, and even lowly Access.) I haven't actually tried SAPDB, because it looks like a major investment of time.

    9.) Books, web sites, and other literature are readily available for MySQL and PostgreSQL. SAPDB's included documentation is most excellent, however, followed by MySQL's included docs. PostgreSQL suffers in this area -- buy the books.

    10.) As I scale up, I probably will have to consider something other than PostgreSQL, like SAPDB, DB/2, or Oracle. I refuse to look at Sybase or especially it ancestor, SQL Server. On the other hand, PostgreSQL is semi-tunable and the development team plans to be adding replication, etc., in the coming months. I'll have to wait-and-see. If SAP ERP can be hosted on SAPDB, then, well, it'll scale, no question. I'd contact the author of BinaryCloud for more objective info, here. http://www.binarycloud.com/

    11.) Warning, total subjectivity: something about PostgreSQL seems "clean," compared to MySQL. I can't say what it is, but there is a big lack of business-likeness to MySQL, other than what I listed above. I'm sure the same is true about SAPDB, and more so, since it's got a real business and an ERP behind it.

    12.) PostgreSQL, like MySQL, has a user-friendly SQL command line, with readline support, etc. I don't know about SAPDB, but I expect it to be less so, like Oracle's SQL*Plus. Can somebody help me out, here?

    In conclusion, my first choice, for now, is PostgreSQL, my second would be SAPDB, my third is actually MySQL, followed by the commercial products. Again, I've never used SAPDB, but I hope to, in the near future; it seems "too big" for my needs, now, and information, outside of sapdb.org is scarce. I hope the community really gets around it, soon, so we can have a more objective look at the product. We need support groups and books available at our local book stores.

    SAPDB looks absolutely excellent, while PostgreSQL looks good. MySQL has potential to be a business/enterprise-ready product, in a couple of years. I like the fact that SAPDB uses ODBC/UDBC for its native calls, like SQL Server, Access, and DB/2. MySQL, PostgreSQL, Oracle, and the like, require drivers to translate calls back and forth, slowing things down and adding complexity, for ODBC, UDBC, and JDBC.

    For PostgreSQL, I gotta say, the thing that really impressed my was versioning, which makes transaction support and hot backups easy, while keeping performance very, very high.

    Try out both databases. Use PGSQL today and SAP tomorrow, as you grow into it.

  7. Re:From using MySQL/PostgreSQL and researching SAP by mikehoskins · · Score: 2, Informative

    I also failed to have you look at Firebird/Interbase -- I wasn't thinking. Firebird might be a PostgreSQL killer. I have actually seen a web host, or two, with Interbase/Firebird support.

    Almost all of the PostgreSQL/SAPDB advantages are available to Firebird/Interbase.

    My list:
    PostgreSQL (for now)
    SAPDB or Firebird (future growth)
    MySQL 4.1+ (maybe, maybe not)

    I have done less research about Firebird than SAPDB. All 4 give a great deal of choice. Firebird is based off of Interbase and has a userr community probably larger than SAPDB. SAPDB still kills Firebird/Interbase and PostgreSQL in terms of enterprise features.

  8. Re:From using MySQL/PostgreSQL and researching SAP by Anonymous Coward · · Score: 1, Informative
    I refuse to look at Sybase or especially it ancestor, SQL Server.

    I think you meant it the other way around. MSFT bought a copy of Sybase and it became SQL Server.

  9. Different personalities by PizzaFace · · Score: 3, Informative
    PostgreSQL and SAP DB are both good products. A few differences I've noticed might influence your choice:
    • Platform independence: SAP DB supports Windows better than PostgreSQL does. They both have good support for unices of various flavors.
    • Concurrency: Both databases support ACID transactions. PostgreSQL uses multi-version concurrency control so reads and writes won't interfere with each other, while SAP DB uses row-level locking. In this respect, PostgreSQL v. SAP DB is similar to Oracle v. DB2.
    • Curriculum vitae: PostgreSQL originated at Berkeley, and has very cool features like MVCC and functional indexes. SAP DB descends from Adabas D, which was marketed as the PC-sized little brother of Adabas for mainframes, and SAP's focus is on providing robust support for business applications such as SAP's customer-relations and supply-chain products.
    • Developers: PostgreSQL is developed by a global community of volunteers. SAP DB is developed by a team of employees (FAQ says 100) in a major software company. Development of both products is active.
    You can do good work with either product.