The Oracle database has been the gold standard for enterprise applications for a long time now. It has great performance, solid reliability and most of the features that you could want are available. The big problem is that it is expensive. And I mean REALLY expensive. That’s just for the base product as well. All of the extra features that you might want are chargeable extras which means that wench developing for Oracle, you often have to work without some of the more advanced features because they would cost too much.
Other issues that I have with it are that you are locked in to the Oracle Ecosystem. Sure, there might be a solution to all the problems that you face or products to address any need but, its always the one sold by Oracle and there is no space for you to exercise flexibility or creativity to implements a better or more suitable solution.Oh yes, and they all cost extra as well.
In Postgres, there are generally several solutions to any problem and if none of them are quite right, you can almost always tweak them yourself (assuming the required programming knowledge) to get exactly what you want. That requires a different mindset and can be somewhat daunting, but ultimately gives you more options and ability to create exactly what you need.
Oracle is a big, complex system which does not lend itself to rapid development and tends to be a barrier rather than an enabler to developers. For example, you can get Postgres up and running in a couple of minute and can easily automate the process so that developers can build and tear down local development environments so that they can experiment easily and quickly. The same is not really the case with oracle, which typically uses a much larger base install.
That all sounds great but if Postgres is so good then why doesn’t everyone just use that and save money?
Well, to a degree they do. It would be rare to find a startup that is choosing Oracle to build a new database. The problems arise when you are already on Oracle and want to switch. Firstly, the Oracle Corporation are really good at business! The number one reason that stops companies from moving are the contracts. Typically, once you have bought a license you are required to pay support costs for that license even if you don’t use it. So if you are paying for it anyway, there is no benefit to trying to switch.
Another issue is that it’s scary! The old saying that everyone knows (I don’t know if it’s true or not) is that no one ever got fired for spending money on Oracle. (Thinking abut it, that would be a great one for Oracle to have started!). This one does make sense. If you have a working system, it is a big risk to try to move it to another database to save some money. It probably seems like more of a risk than it actually is because you can mitigate most of the risks with careful planning but it is a risk non the less.
There is a general impression that Oracle is faster than Postgres. I find this one a bit confusing because I have looked hard and can’t find any evidence of published comparisons. (If you do have any, please let me know as Would like to see them) I may be wrong but I believe that Oracle make this comparison difficult with non disclosure clauses in their contracts which would stop customers from releasing figures like this.
It’s hard to compare 2 databases in terms of real world throughput. You first have to have realistic workload that you can replay for both databases and it should be identical otherwise its not a fair test. Then you have to have identical hardware. Then you need to measure the maximum throughput and assume that it translates real world usage. Of course, even if you manage that, it’s not going to give you a perfect result because that is not how you use a database the real world. You would start with a base setup and tune it based on throughput, slow queries and bottlenecks. If you do that though, you aren’t comparing like for like all you could really compare would be your ability to tune the 2 systems.
It’s entirely possible that Oracle is faster than Postgres for some or all usage patterns. I am not sure that that would really be relevant though. Its rare that you run your system at maximum throughput for any length of time and besides, I know from first hand experience that Postgres can handle very high volumes of throughput and data sizes comfortably and perhaps more importantly gives you many options to scale when you do start to hit a ceiling.
I’m going to try to break this comparison down to a few key areas and see how the 2 systems compare.
Value for money
There is no comparison here. Oracle is expensive and Postgres is free. The larger picture including the TCO might be a bit more complicated but the main other costs associated with running a database system – hardware and people should be approximately the same so we can safely say that Postgres wins this one. This will be the biggest reason for organizations to make the switch.
Functionality
This one is a drawing my opinion. I have not seen anything that can be done in Oracle that you can’t do in Postgres and of course, it is much easier to add extra functionality to Postgres because of its extension system than it is in Oracle. Scalability
Another draw. Both Oracle and Postgres can scale to huge sizes. They can both handle huge data volumes and provide options for various types of horizontal scaling.
Compatibility
This one goes to Postgres. You can write functions to run int he database in pretty much any language and if something isn’t already supported, you can add it because there are straight forward ways to hook into the system in Postgres. With Oracle, you have a very strong function language in PL/SQL and some other languages are supported but it the one you want to use is not supported then you are out of luck.
Support
This would seem to be in Oracles favor at first but its actually a bit more complicated than that. With Oracle you have support automatically. It’s part of what you pay for. There is an obligation to fix bugs but don’t expect miracles. In Postgres, support tends to be through the community. People are very helpful but of course, there is no obligation to provide a fix. If you do find a genuine bug then you will probably be heavily involved in diagnosing it and may fine that the fix does not make it in until the. Next release. Of course, it is completely possible to buy support and you can do this for a fraction of the cost of Oracle. Both Enterprisedb and 2ndQuadrant (among others) provide their own versions of Postgres which they will support and provide bug fix guarantees for. There are also many companies providing technical support. The big difference is that your DBA’s must be prepared to get much more involved with fixes with Postgres than they would with Oracle.
So when should you choose Postgres and when should you stick with Oracle?
If I was a bank running an already existing Oracle database to keep track of financial transactions, I would be very wary of making a switch. Not necessarily because of any limitations in Postgres but rather because the risk of any more is simply too great and the costs of mistakes in the process could be catastrophic.
If I was a startup picking a database for a new project (and the choice was for a rdbms) I would pick Postgres 100% of the time. There is no reason to go with a more expensive option that does the same thing.
The question is really the most important for those in the middle with an existing Oracle Database that they are thinking of switching.
Technically, I think Postgres could run whatever you are running on Oracle. The decision should come down to how comfortable you are with the upheaval of the migration process and the severity to your business of any mistakes or downtime.
You will be able to ultimately get to parity and long term savings but it will require working commitment to get there. You need to balance that against the large financial savings you can make.
