Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Derby vs PostgreSql Performance Comparison

We are doing research right now on whether to switch our postgresql db to an embedded Derby db. Both would be using glassfish 3 for our data layer. Anybody have any opinions or knowledge that could help us decide?

Thanks!

edit: we are writing some performance tests ourselves right now. Looking for answers more based on experience / first hand knowledge

like image 246
Austin Avatar asked Jan 26 '10 18:01

Austin


People also ask

Is PostgreSQL faster?

PostgreSQL is faster when dealing with massive datasets, complicated queries, and read-write operations. On the other hand, MySQL is known to be faster for read-only commands.

Is PostgreSQL outdated?

The PostgreSQL Global Development Group supports a major version for 5 years after its initial release. After its five year anniversary, a major version will have one last minor release containing any fixes and will be considered end-of-life (EOL) and no longer supported.

Does Derby use SQL?

Derby does not have an SQL create database command. ; The semicolon is the ij command terminator. Create a table with two columns using standard SQL.

Why do people prefer PostgreSQL?

PostgreSQL isn't just relational, it's object-relational and supports complex structures and a breadth of built-in and user-defined data types. It provides extensive data capacity and is trusted for its data integrity. This gives it some advantages over other open source SQL databases like MySQL, MariaDB and Firebird.


1 Answers

I know I'm late to post an answer here, but I want to make sure nobody makes the mistake of using Derby over any production-quality database in the future. I apologize in advance for how negative this answer is - I'm trying to capture an entire engineering team's ill feelings in a brief Q&A answer.

Our experience using Derby in many small-ish customer deployments has led us to seriously doubt how useful it is for anything but test environments. Some problems we've had:

  • Deadlocks caused by lock escalations - this is the biggest one and happens to one customer about once every week or two
  • Interrupted I/Os cause Derby to fail outright on Solaris (may not be an issue on other platforms) - we had to build a shim to protect it from these failures
  • Can't handle complicated queries which MySQL/PostgreSQL would handle with ease
  • Buggy transaction log implementation caused a table corruption which required us to export the database and then re-import it (couldn't just drop the corrupted table), and we still lost the table in the process - thank goodness we had a backup
  • No LIMIT syntax
  • Low performance for complicated queries
  • Low performance for large datasets

Due to the fact that it's embedded, Derby is more of a competitor to SQLite than it is to PostgreSQL, which is an extremely mature production-quality database which is used to store multi-petabyte datasets by some of the largest websites in the world. If you want to be ready for growth and don't want to get caught debugging someone else's database code, I would recommend not using Derby. I don't have any experience with SQLite, but I can't imagine it being much less reliable than Derby has been for us and still being as popular as it is.

In fact, we're in the process of porting to PostgreSQL now.

like image 151
Dan Avatar answered Oct 01 '22 20:10

Dan