Compatibilty wars - can EnterpriseDB take on Oracle and win?

EnterpriseDB has been on a mission to replace Oracle's database with its enhanced version of the open source postgreSQL database (Postgres Plus Advanced Server) for quite some time. When Oracle announced that they were halting development for HP's Itanium-based HP-UX UNIX systems, EnterpriseDB stepped in to offer their product as a replacement. While this was a bold marketing move, I would suggest a careful consideration of what such a migration would entail before taking on such a project.

Database servers are complex

Database severs are one of the most complex types of software ever developed. To achieve the level of performance and scalability customers need, database suppliers have had to develop their own memory management, file systems, clustering and several other capabilities normally reserved for operating systems. Achieving total compatibility is a nearly insurmountable task.

What would be needed for complete compatibility?

Total compatibility would require spot-on emulation of the following things:

• Scripting language
• Functions
• Triggers
• Stored procedures
• Libraries of standard packages
• Either the ability to support user-developed packages or a way to convert them transparently

Furthermore, it would be necessary for a replacement database server to process SQL statements in precisely the same way, have the same known bugs and deal with collections of data precisely as the original database does.

Tall order

When is good enough good enough?

If the emulation offered by a competitor was 90% complete would that be enough? This requires a yes and no answer. The answer is yes if a given customer's applications used only the features covered by the 90% compatibility. The answer is maybe if the customer's code used the 10% of the database server's features that incompatible with the potential replacement's features. If a supplier has very easy ways to reproduce those features in other ways, the migration might be viable.

What to do when a supplier kills a product offering you need

Oracle clearly put some of its customers, those who had selected HPs Itanium-based systems as a part of their IT infrastructure, to the fire. These customers are now faced with a choice between three options: staying where they are, changing out their hardware platform or changing out their software platform.

Staying where you are

Some companies will continue to use their current HP systems with their Oracle database servers until they will no longer function at all. They will do something only when what they're doing now no longer can be made to work.  In their view, they'll consider a migration only when the cost of maintaining their current solutions is higher than making a migration. Only then will they consider other options.

Changing out the hardware

This option, the one Oracle clearly favors, means replacing systems, system software, management software, development tools, application software as well as the database server software. It will also require replacement of server attached storage devices as well. This is a very costly approach.

Oracle is hoping that its customers will chose this path and replace the HP Itanium-based servers with one of its own Sun servers.

Changing out the software

This option, the one that enterpriseDB clearly favors, means replacing just the database server software and making only the necessary changes to everything else. While it is true that system software, management tools, development software and server attached storage can be preserved, costly changes to application software may be required.

EnterpriseDB is hoping that this option appears to reduce the cost of change so much that Oracle's customers will examine something from a much smaller, less well known company.

Snapshot analysis

Since every company's environment is a bit different than all others, there is no single cut and dried solution. I project that most companies finding themselves caught between Oracle and HP will stay the course and continue using their current systems and their current software until they are literally forced to change. I have doubts that many companies will switch out hardware because of the high costs of this option. A number will consider enterpriseDB as an option.

Now is the time for EnterpriseDB to publicize success stories to encourage the consideration of the approach they suggest, moving from Oracle's database server to EntepriseDB's PostgreSQL-based product. All it would take to dash EnterpriseDB's hopes is the emergence of a few horror stories about migration failures.