YugabyteDB Migration: What About Those 19 Oracle Features I Thought I Would Miss?

In 2019, I gave a presentation with the title, “19 features you will miss if you leave Oracle.” The talk focused on features used every day with Oracle—and those that may not be available in other databases. However, the goal of this presentation was not to influence any decision or outcome. 

Migrating from a commercial database is not about covering a full set of features. It’s a strategy to stay in control of the software that processes and stores enterprise data. But knowing the features you may miss—or have to workaround—is important to avoid surprises. 

I’ve been asked if I miss those features (or not) now that I’m a developer advocate at Yugabyte. In this blog post, I’ll examine them one by one, and show how YugabyteDB, the open source, high-performance distributed SQL database, stacks up as a more-than-viable alternative. 

1. lock-free SELECT

YugabyteDB has no locks. It has roots in optimistic locking, which avoids surprises with response time and prevents non-scalable waits. In case of a transaction conflict, users receive an error and have to retry the transaction. This means that the application code handles it. However, if the application is unable to do so, issues will crop up in a highly-available system. In such a system, in case of failover to another node, the current transaction cancels and retries when re-connecting.

YugabyteDB’s default isolation level is SERIALIZABLE. This is higher than the Oracle one with the same name. Of course, this approach may not be the one expected by legacy applications that rely on pessimistic locking. That’s why YugabyteDB supports the lower isolation level READ COMMITTED. But the idea is still non-blocking reads, similar to Oracle or PostgreSQL.

You can continue reading the rest of this post on Franck’s Medium site. And don’t forget to take YugabyteDB for a spin by downloading the latest version of the open source.