One thing I haven't seen anybody commenting on is the fact that with SAP acquiring Sybase, it will be the last major independent database company to be merged into a larger SW company. (To say this, you can qualify MySQL AB as a major database company, but disqualify, say, EnterpriseDB or InterBase, which imho is entirely reasonable.)
It used to be that only DB2 was initially developed by IBM, whereas Oracle, Sybase, Informix, InterBase and of course MySQL, where all database companies focusing on the database. Out of these, Oracle has acquired itself into a full stack player, others have been acquired into a larger portfolio, or just died out. Sybase has kind of been acquired twice now, since Microsoft SQL Server is based on an "IPR acquisition" of the Sybase code, and now then the real Sybase acquired by SAP.
So what should one think about this? It seems that the RDBMS database has grown into an integral part of your software stack, and the big software houses therefore want to control their own operating system, an app server and a database. Except that this doesn't sound right to me...
In the operating system space we have a clear trend where Linux is used by everyone, and other unixes such as by IBM or Sun, now Oracle, are more or less considered legacy. Microsoft is the only one who still manages to maintain a strong stack of its own, people who develop on Windows and .NET are kind of in their own universe and not much affected of what happens with Linux or elsewhere.
In the app server space you are not supposed to care too much about which one you use either (again, .NET being in an alternate universe).
So why isn't this the case with databases?
I don't know. My standard answer is that databases will follow the same trends towards open source, but the database market moves slower, that's all. A major ISV reported (as part of the EU hearings on the Oracle acquisition of MySQL) that of their customers, only 2% per year migrate from one database to another. That's a very stagnant industry to me.
As for me, I will continue my little part to work for a similar trend in the database layer as we already see in the operating system layer: that there will be an open source database that everyone can use and share and collaborate on, rather than everyone acquiring their own.
- Log in to post comments
- 14859 views
"So why isn't this the case
"So why isn't this the case with databases?"
I think for several reasons. Language standardization on app servers is quite easy to achieve since there aren't many dialects for modern programming languages.
With SQL and databases? not so much. Usual suspects are DDL syntax, data type support, built-in functions, and stored procedure language. And even though there is a SQL standard, it is so huge and complex that there are almost no implementations that get all of it right (let alone complete). For example, something that should be really simple, like string concatenation is a major source of incompatibility even among major databases.
Add to that that managing databases, especially larger ones, is an expert job. There is not much time beyond just doing your job, and you end up with a lot of knowledge and skills which are highly specific for a particular data base platform. So employees are married to their database, companies are married to their employees and the result is almost nobody can move their apps to a different RDBMS. If you develop a product from the ground up to be compatible with multiple datases, you have a chance, but it hugely impacts productivity and time to market.
"So why isn't this the case
"So why isn't this the case with databases?"
I think for several reasons. Language standardization on app servers is quite easy to achieve since there aren't many dialects for modern programming languages.
With SQL and databases? not so much. Usual suspects are DDL syntax, data type support, built-in functions, and stored procedure language. And even though there is a SQL standard, it is so huge and complex that there are almost no implementations that get all of it right (let alone complete). For example, something that should be really simple, like string concatenation is a major source of incompatibility even among major databases.
Add to that that managing databases, especially larger ones, is an expert job. There is not much time beyond just doing your job, and you end up with a lot of knowledge and skills which are highly specific for a particular data base platform. So employees are married to their database, companies are married to their employees and the result is almost nobody can move their apps to a different RDBMS. If you develop a product from the ground up to be compatible with multiple datases, you have a chance, but it hugely impacts productivity and time to market.
Linux is a commodity, DBMSes are not
One Linux is pretty much the same as the other Linuxes for the most part. Something that works on Redhat or Centos will generally work on Ubuntu or SUSE for the most part. Databases are not as fungible so you can't change them as easily.
But why isn't DBMS a commodity
First: to clarify a little, I see two dimensions about Linux: It has commoditized the OS market against the traditional proprietary UNIXes. Then also, what you point out is that there are many vendors with their own Linux, so among Linux vendors one piece of SW will work on all of them.
But my question is, why isn't this the case in databases? You could have multiple Postgres or MySQL vendors, but we don't have that.
My answer is that it's just happening more slowly than it did on Linux. ...for many reasons, some specific to the DB industry, some perhaps specific to MySQL and Postgres as projects being different than Linux.