Okay, I know what you’re thinking, how can a guy from Exasol really give an impartial opinion on Oracle’s database? But I’m not here to sell you anything and I definitely don’t work in marketing. What follows is simply my personal experience and opinion as someone who’s used both and worked in this industry for more years than I care to mention.
It’s not that easy though. Coming from Oracle as I do, much in Exasol’s analytics database looks quite familiar on the surface. Both are Loading...relational databases with a transaction management system that supports the ACID model. Both follow the ANSI SQL standard – both with some enhancements. So let’s take a more detailed look and see what sets them apart.
Oracle is the leading technology for online transaction processing (OLTP). If you have a high data volume with many users doing concurrent changes, this is where Oracle shines.
But our database is the leading technology for analytical workloads. So if you want to do real-time ad-hoc reporting on high data volume, this is where our analytics databse excels.
Data format and Loading...in-memory processing
Oracle uses a row-oriented data format. This is well suited for OLTP but not so much for analytical workloads. That’s why hybrid columnar compression (only available on engineered systems on Oracle proprietary storage) and an Loading...in-memory column store (extra-charged option) have been added.
Our analytics database uses a compressed columnar data format natively and processes this format Loading...in-memory. It’s very good for analytical queries but less so for OLTP because one data manipulation language (DML) session on a table locks that table against DML from other sessions. Read Consistent SELECT is possible for other sessions, though.
Oracle was designed for OLTP when memory was scarce and expensive. Ours was designed to process analytical workloads, Loading...in-memory.
Oracle started as a non-clustered, or single instance, system. Real application clusters (RAC) were added much later. The majority of Oracle installations are still non-clustered. The extra-charged option of RAC is an exception rather than the rule. Most RAC installations are two-node clusters with availability as the prime reason and scalability is a side effect.
Exasol designed their analytics database from the start to run on clustered commodity Intel servers. The main reasons for this were massive parallel processing (Loading...MPP) performance and scalability with availability as a side effect.
This only matters for RAC and not for most Oracle installations. Oracle uses a shared disk architecture for RAC while Exasol uses a shared nothing architecture. This is ideal for performance because every Exasol cluster node can operate in parallel on a different part of the data. One drawback is that after adding nodes to an Exasol cluster, the data has to be re-distributed.
With Exadata, Oracle tries to compensate the performance disadvantage of the shared disk architecture by enabling the storage servers to filter data locally for analytical workloads. This leads to a better performance than Oracle can deliver on other – non-proprietary – platforms.
Availability and recoverability
Oracle is better in this area. A non-clustered Oracle database running in archive log mode, lets you recover every single committed transaction you did since the last backup. With Exasol, you can only restore the last backup – all other changes will be lost.
Oracle databases can be safeguarded against site failure with a standby database at a large distance without impacting performance. Exasol doesn’t have that. With RAC, you can protect an Oracle database against node failure. The database stays up, although the global resource directory is frozen for a couple of seconds on node failure but without data loss.
If an Exasol cluster node fails, it leads to a database restart. This means there’s no availability for a couple of seconds and all sessions get disconnected, but no data is lost. Optionally, Exasol can be configured as a synchronous dual data center – similar to Oracle’s extended RAC.
Complexity and manageability
I realized that there’s a big difference between Exasol and Oracle in this area while teaching an Exasol admin class. Some seasoned Oracle database admins kept asking questions like “We can do this and that in Oracle – how does that work with Exasol?” when creating materialized views, bitmap indexes or an extra keep cache, for example. My answer: “We don’t need that with Exasol to get good performance”.
An Oracle database is probably one of the most complex commercial software products ever developed. You need years of experience to administer it with confidence.
This Oracle Database Administration manual gives you an impression – on 1690 pages. And that doesn’t include Real Application Clusters, covering an additional 492 pages. So you need to dig through over 2100 pages of documentation. After having worked with Oracle for over 20 years, I can proudly say that I actually know most of it.
In comparison, Exasol is very easy to use and manage, because the system largely takes care of itself. That’s why our admin classes last only two days and attendees feel empowered to manage Exasol afterwards.
That approach was intentional. Exasol customers aren’t supposed to study the database for years or pay someone to do in order to get great performance. Oracle realized that being complex and difficult to manage is an obstacle and created the Autonomous Database. But that’s only available in the proprietary Oracle Cloud.
Using comparable hardware and processing the same analytical workload, Exasol outperforms any competitor. This includes Oracle on Exadata.
Our presales consultants regard Exadata as a sitting duck, waiting to get shot on a proof of concept (POC). I was pretty shocked to find that out after drinking the Oracle Kool-Aid myself for years.
In my opinion, two points are important: Exasol is faster and at the same time much easier to manage. Lots of things could be easy to manage, so that’s not an asset on its own. But together with delivering striking performance, it’s a really big deal.
This is and has always been a pain point for Oracle customers. The Oracle database license is so complex and granular that you always wonder “Am I allowed to do this without violating my license? Do we really need these features that we paid for? Are we safe if Oracle does a license audit?”
With Exasol, all features are always included and the two most popular license types are totally easy to understand. You pay either for the data volume loaded into the cluster or for the amount of memory assigned to the database.
This becomes increasingly important as many of our new customers want to deploy Exasol in the cloud. And you may have noticed that Oracle continues to push the cloud option for the last few years.
Exasol runs with all features enabled in the cloud. You can choose between Amazon Web Services (AWS), Microsoft Azure and ExaCloud
The most popular way our customers run Exasol in the cloud.
Microsoft’s cloud can also be used to run Exasol. This allows you to choose between two major public cloud platforms.
Hosted and managed by Exasol, ExaCloud is a full database-as-a-service offering.
Hybrid Exasol deployments that combine cloud with on-premise can also be used, depending on customer requirements.
Oracle offers RAC only on the Oracle Cloud platform, not on public clouds. The availability of various other features is also restricted to Oracle’s own cloud. The licensing model generally favors the usage of Oracle’s own cloud over others.
Oracle is great for OLTP and okay for analytical workloads – especially if you pay extra for partitioning, RAC, Loading...in-memory column store and Exadata. Then the performance you get for your analytical workload might suit your present demand.
Exasol is not suited to OLTP but comes absolute tops for analytical workloads. So the question is – do you think your data volume and your analytic demands will grow?