Is the relational database now a commodity?
Your thoughts on the past and present
Reg Reader Workshop For those of us who were around in the industry during the mid to late 80s, it is interesting to think back to a time when vendors of relational database management systems (RDBMS) were struggling to be taken seriously.
The line up then was DB2, Ingres, Informix, Oracle and Sybase, and back in those days RDBMS specialists took pride in being able to tune engines and database designs to get the most out of these very special beasts. In expert circles, debates would rage over the relative merits of multi-threaded versus multi-engine servers, row versus page level locking, the efficiency and performance of stored procedures versus the standard nature of raw SQL, and so on.
These were the days when Sybase SQL Server would come pre-configured out of the box with 4MB of cache and many users actually ran with that default. And the largest database size? Well, there was a race in the industry between vendors who could come up with the first reference site with a 1GB database, then Sybase started its "1GB Club", which was made up of some of the largest and most adventurous users.
It is a little sad when us old pioneers hear people talking about the RDBMS now being a commodity, but who are we to argue when you can download and run MySQL - an engine that is much more powerful and versatile than anything we were working with the early days - for zero cost? You can even get a community version of the previously "big iron" DB2 from IBM for free.
There is a counter-argument, however, that while basic RDBMS server functionality to handle structured relational data probably has become commoditised, the world has moved on. From a physical perspective, for example, platform architectures are a lot more sophisticated and varied, and today we have to think about everything from stand alone small footprint servers, through clustering, blade servers, and virtualisation, to full blown grid computing. The type and range of information that needs to be managed is also quite different – XML documents, binary documents, graphics, video, voice and geo-spatial data.
We have then seen the RDBMS assume new roles. While specific analytical servers to support business intelligence are still in demand, for example, more and more organisations are using the analytical features that are now embedded natively in mainstream RDBMSs to build very functional data warehouses (see chart).
Finally, there are the modern-day requirements for openness and interoperability, and the sheer performance, scalability, and resilience characteristics necessary to handle high volume transaction systems, busy 24/7 public facing websites, and highly dynamic data warehouses to quench the ever growing thirst for the latest business performance information among business users.
Against this background, is it really just a case of picking any old RDBMS and running with it for the job at hand? If we had true commoditisation, this would be the case.
So what do you think?
We know you have something to say on how the requirements for database management systems have evolved and what will be important in the future, so give us your thoughts in the discussion areas below. ®