DBMS transparency layers never seem to sell well
A DBMS transparency layer, roughly speaking, is software that makes things that are written for one brand of database management system run unaltered on another.* These never seem to sell well. ANTs has failed in a couple of product strategies. EnterpriseDB’s Oracle compatibility only seems to have netted it a few sales, and only a small fraction of its total business. ParAccel’s and Dataupia’s transparency strategies have produced even less.
*The looseness in that definition highlights a key reason these technologies don’t sell well — it’s hard to be sure that what you’re buying will do a good job of running your particular apps.
This subject comes to mind for two reasons. One is that IBM seems to have licensed EnterpriseDB’s Oracle transparency layer for DB2. The other is that a natural upgrade path from MySQL to Oracle might be a MySQL transparency layer on top of an Oracle base.
At first blush, the Oracle/MySQL possibility could break the mold. Migrating from one product to another product owned by the same vendor is a lot different than migrating from one vendor’s product to another’s. Users have tremendous familiarity with upgrades where one vendor controls both the start and end points of the transition.
On the other hand, the number of cases where a vendor has bought a DBMS product and then migrating a substantial user base over to another DBMS is approximately zero. The template for reasonably successful DBMS vendor consolidations — such as IBM/Informix or Oracle/RDB — is almost always to maintain and enhance multiple product lines side by side.
As for EnterpriseDB/DB2 — if you have an application running on Oracle, why port it to DB2? Unless IBM gets aggressive on its maintenance licensing terms, that won’t even get you much of a first-glance cost saving. And while it’s annoying to do DBA work for two database brands when one will suffice — if you have those Oracle apps already running, then you also already have the DBA resource to keep them going. No doubt there will be situations where this new offering is useful and welcome, but they’ll probably prove to be rather isolated edge cases.
A couple of years ago, I did make a theoretical argument that DBMS portability should become technically easier and hence more widely adopted. But since then I’ve seen very little practical evidence to back it up.
Comments
11 Responses to “DBMS transparency layers never seem to sell well”
Leave a Reply
Curt,
I agree with you that transparency layers do not work well, BUT DB2 does not have an Oracle transparency layer (and neither does EnterpriseDB as far as I know).
What DB2 has is native support for PL/SQL and the Oracle SQL dialect.
When you pitch a PL/SQL and and SQL PL against each other on a DB2 system you will find that they perform equally fast by design.
There is no simulation translation adding latency or emulation hurting performance.
Think of PL/SQL as another “skin” to the DB2 engine not an additional outer layer of clothing.
Also in the cost of an application the DBMS licensing cost is only one part.
Storage savings alone can be significant.
Cheers
Serge
This makes me think of the formulaic use in enterprise programming of 3-tier and 4-tier models, where the benefit stressed is the ability to change the underlying database and/or data structure details without breaking higher-level code.
I have seen this work in a few cases. But I think enterprise projects where there is a need to change databases are fairly rare. It’s not always worth building the necessary infrastructure for database transparency.
The “You Ain’t Gonna Need It” principle is a compelling one and it can be a losing game to try to predict where flexibility will be needed. I think in many situations where one would need the kind of flexibility a transparency layer offers, the overall situation has changed and you are going to be reworking all the layers anyway.
Most of the above could apply to off-the-shelf software or built-in features that offer db transparency. All in all, it seems to me like a solution to a problem that customers might have later, not a problem they have now.
Serge,
I think that’s almost a distinction w/o a difference, because the problem rarely is performance loss due to translation/interpretation/whatever. Much more often it’s either a missing feature, or else one that just inherently performs slowly due to some architectural difference. An extreme case of the latter would be SQL layered on top of IMS and other hierarchical/CODASYL/whatever systems, which took many years to be respectable.
[…] Will many people bother to port? Haven’t we seen this game before? IBM has not done many migration programs. They’ve tried, and so have others, before, and none were all that successful. Curt Monash asks the question, and he’s absolutely right to, here. […]
having worked in an academic niche stuck on Sybase (whereas most all the other academics nearby were at least on Oracle), i’m totally a believer that porting to another db mostly never really happens.
people say that it can happen and that their ORM is the tool that will let them do it, but inevitably there are things which don’t go through that ORM, or people punch holes straight through it to take advantage of db-specific features.
if people were serious about being able to be abstract, there would be a least-common-denominator software layer that could pretend to be a unified db, but be run on top of any other db engine as the back-end. of course, this would suck in all sorts of fun ways so nobody does it.
I agree with Raoul Duke’s comment that a big problem is that there are often things that don’t go through the ORM. (Perhaps not “inevitably”, but it’s more likely for large, high-performance systems.)
The most obvious thing is the use of PL/SQL procedures inside the database system. There are other things, though: suppose you’re depending on Oracle RAC for high availability? Suppose you’re using datatypes that aren’t available on the other DBMS? Suppose you’re using Oracle Dataguard for disaster recovery?
I can see it being relatively easy to port low-end applications, that don’t happen to need Oracle-only features, or which were carefully built to avoid Oracle-only features specifically to aid porting in the future. When you say that it’s been rare to see ports from one RDBMS to another, I presume you are talking mainly about large, high-performance applications. I believe (someone correct me if I’m wrong) that Drupal is capable of running on more than one RDBMS; MySQL is used on most Drupal installations, but not on all (source: a top engineer at Acquia).
Dan,
Obviously, third-party software commonly supports multiple DBMS. I don’t even know what point you’re making by pointing that out.
There also are tons of cases in which, when it’s time to rewrite something, the newer version winds up on a different DBMS (MySQL to Oracle, Oracle to an analytic DBMS, legacy DBMS to enterprise standard, whatever).
What I’m saying is that if an application works well enough to not be rewritten, it usually also works well enough not to bother porting from one underlying DBMS to another.
Indeed, I’d have replaced “DBMS” with “platform technologies” in that before the virtualization movement, except in the case of routine upgrades.
Curt,
There are three rough areas that I like to divide DB2’s compatibility features into:
1) Syntactic Differences such as (+) vs. LEFT OUTER JOIN, or MINUS vs. EXCEPT
2) Impedance mismatch
E.g. Oracle’s PL/SQL was without a doubt more expressive than DB2’s SQL PL.
Therefore any mapping has to use workarounds and these workarounds are slow. I think of that as “emulation”
Think associative arrays vs declared global temporary tables here.
3) Semantic clashes
The two just can’t talk to each other because the same word means a completely different think
This is teh case with DATE or VARCHAR for Oracle vs. DB2.
DB2 9.7 attacks all three of these fronts.
For a business partner it is very intersting to not have to maintain two or more code bases to offer their customers their choice of DBMS or to negotiate teh best OEM price for themselves.
In the past you either had to choose an abstraction layer (make the problem a Java problem instead of a DBMS problem) with the obvious loss of performance, or you had to just pay th price of dual maintenance.
Business partners are thrilled that they can now support DB2 and Oracle with the same source code without having to restrict them selves to teh equivalent to SQL baby talk.
Cheers
Serge Rielau
SQL Architect, DB2 for LUW
[…] this isn’t all bad news. EnterpriseDB’s Oracle-compatibility focus had to be changed anyway. And Fred Holahan was the proximate cause for me writing: my recent dealings with EnterpriseDB […]
I respectfully disagree. Forrester Research, also disagrees:
http://www.computerworlduk.com/community/blogs/index.cfm?entryid=3058&blogid=25
“I estimate that so far, some 300 companies have migrated their databases using the database compatibility layer, and this is likely to become the standard approach for database migrations in the future.”
[…] Smart IT managers recognize this. That’s why such ’solutions’ “never seem to sell well, says analyst Curt Monash. […]