5 Questions to Help You Avoid Oracle Compatibility Imitators

Contributed by Gary Carter

You may have heard the phrase: Imitation is the sincerest form of flattery. It implies that competitors doing what you already do validate your actions without explicitly saying so. It also implies that the imitator is actually delivering what you are. Over the last decade, EnterpriseDB^® (EDB™) has experienced great success helping organizations migrate off of Oracle^®. During this time, EDB also has come across a number of imitators claiming their solutions are compatible with Oracle. In these cases, we’ve seen that imitation is the most insincere form of Oracle compatibility, and such flattery has gotten those imitators and many of their customers nowhere. 

There is just one data management solution that is (and sincerely) compatible with Oracle – that’s the EDB Postgres™ Platform. EDB Postgres can natively execute Oracle’s PL/SQL dialect of the SQL programming language, and thus preserve the critical business logic that lives in the database as Table Triggers, Stored Procedures, and Functions. EDB's compatibility technology and tools reduce the technical, re-training, and integration risks of moving off Oracle.

No other company, consultant, or product on the market that promises Oracle compatibility or migration can do that.

This is important because moving data from one SQL database to another has been a relatively easy task for many years now and does not equate to database compatibility. Clearly, data is important. But it’s what you do with that data that is most important.

Making data compatible is not the hard part of compatibility.  The hard part—the important part—of compatibility is avoiding a re-write of all your critical business logic. This code ensures critical additional data updates, executes important processes managing data inside the database, coordinates with other programs outside the database, and provides all manner of data manipulation and logic. Programming logic in any form is extremely difficult to get right and requires highly skilled programmers, extensive testing, in-the-field experience, and often, years of fine-tuning to fully optimize your business processes.

Re-writing business logic is fraught with risk. It introduces the possibility of new bugs, breaking long-standing processes affecting your bottom line. It takes longer to test and debug, and misses more deadlines, typically than other kinds of processes. And, it introduces incompatibilities for integration into an Oracle environment that may still persist with you for some time. 

When you run into imitators claiming Oracle compatibility or migrations, you really need to ask yourself some tough questions:

    1. Do I really want to re-write all that business logic that has taken years to perfect?
    2. Is re-writing my Oracle database business logic a task I want some consulting firm to promise they can do in a few months?
    3. Is keeping my existing business logic easier, safer, and quicker?

And you also really need to ask that open source PostgreSQL consultant some questions too:

    4. Does your claim of compatibility mean my PL/SQL remains unchanged and runs natively?
    5. Can my developers continue using their Oracle PL/SQL skills and code after you migrate my application and will my new application work smoothly with my remaining Oracle infrastructure?

Make no mistake, there is only one organization whose Oracle compatibility can effectively eliminate the need to re-write your business logic, reduce your risks of moving off Oracle, and reduce your database spend in the process.

To learn more about Oracle migration, visit our Migration Portal.

Gary Carter is Director, Field Marketing at EnterpriseDB.