An era of easier database portability?
More and more, I find myself addressing questions of database portability and transparency, most particularly in the cases of EnterpriseDB, Ants Software, and now also Dataupia. None of those three efforts is very large yet, but so far I’d rate their respective buzzes to be very encouraging in the case of EnterpriseDB, non-discouraging or better in the case of Ants, and too early to judge for Dataupia. On the whole, it definitely seems like a matter worthy of attention.
With that as backdrop, where is all this compatibility/portability/transparency stuff going to lead? Potentially, pretty far. The technical barriers aren’t great. Given that, issues of cost, market dynamics, and so on suggest there should eventually be just as much database porting as there is porting between UNIX-derived hardware and operating systems. I.e., a lot.
A DBMS, first and foremost, is a big language interpreter. Therefore, if you want DBMS transparency, most of what you have to do is run the language, without major performance hits. In principle, this shouldn’t be hard, because SQL dialects are pretty similar and pretty simple. And in practice it’s not too hard either.
How do I know it’s not too hard in practice? Because DataDirect (now owned by Progress) has been doing it for years! DataDirect’s main business is translating ODBC and JDBC to native SQL, and it does a bang-up job. Performance hits are usually trivial, and sometimes there even are performance gains from the translation. True, there’s more to full stored-procedure-language compatibility than is commonly found in DataDirect drivers. But EnterpriseDB has been doing a much fuller job of Oracle compatibility without too much evident difficulty. And there’s the Ants example as well.
Of course, it’s not that simple. But much of the non-simplicity lies in this: If you port from one DBMS to another, you may need to totally retune your system to get comparable performance to what you had before. And that’s a costly hassle. Except – tuning is getting ever more automatic and easier. And as hardware gets cheaper, tuning is getting somewhat less important. And specifically on the analytic side, MPP so dominates SMP in price-performance that a port is likely to gain you a lot of throughput with very little tuning effort at all.
“Wait a moment!”, one might say. “The big DBMS companies make huge investments in their products. Unless that effort is utterly wasted, surely they do many things better than some upstart does.” But then, one might also have used the same reasoning to suggest that Linux could never outpace Unix. Or that Unix could never supplant VMS. Or that VMS could never compete with MVS …
Reasons that all of these arguments fail include that lots of the development effort at the big, established leaders:
- Is to compensate for the products’ old and now somewhat obsolete architectures.
- Is to compensate for the products’ giant-hairball natures.
- Is for high-end reliability, availability, security, and/or absolute-scalability features that most users don’t need.
- Achieves extreme generality (portability, language support, etc.) that most users don’t need.
Is for other specialized functionality that most users don’t need. - Suffers from “Mythical Man-Month” inefficiencies.
Industry leaders have been successfully challenged many times in the history of DBMS. As I’ve noted many times in this blog, I think it’s happening again. And transparency/portability/compatibility could well wind up being part – albeit just a part – of that general trend.
Comments
2 Responses to “An era of easier database portability?”
Leave a Reply
Everything old is new again: Ran across a company called Datometry trying to do this again. Interesting to know whether you have seen them, have anything to say about them.
First I’ve heard of them. But Teradata escape doesn’t strike me as a wonderful business proposition.