Intelligent Enterprise

Is database management a mature, commoditized software technology? It depends whom you ask. Start with IE Editor-in-Chief Doug Henschen, who wanted my take last July after he and I each wrote on Oracle 11g. My answer: definitely!, which no doubt confirmed Doug in his intention to later write that Oracle President Charles "Phillips's higher calling was to dispel the idea that database management systems have been commoditized in a mature market."

OK, I admit that the president of Oracle speaks with more authority than I do although he perhaps speaks with more bias as well. I don't have a 47.1% share of the RDBMS market to protect.

Nor is Microsoft's 17.4% RDBMS market share my responsibility. Contrast Phillips with Microsoft Technical Fellow David Campbell, quoted in an interview published in the September issue of Database Trends and Applications magazine. DBTA asked Campbell about factors distinguishing Microsoft SQL Server and its primary competitors. Campbell's response: "For 99 percent of your information-management needs, you can get the job done with SQL Server, DB2, or Oracle." Campbell's conclusion was that "you want to choose the one where your ongoing cost of operations is lowest."

So if you're trying to maintain high prices you deny that your product is a commodity. If you're selling for lower prices to a mass market, you deny that your competition offers sufficient added value that justifies their high prices for commodity technology.

In this instance, I'm with the Microsoft guy. While his 99% figure is both imprecise and an overstatement - he implicitly excludes content-management systems, embedded DBMSes, and desktop data management - he's completely correct that leading relational DBMSes are essentially interchangeable. If all you require is a SQL engine, there are a dozen credible alternatives, and basic functional capabilities become incidental. So far as that functional core is concerned, 1) there's broad consensus on definitions (e.g., relational rules, ACID, b-tree indexing), 2) basic interface standards are well established (e.g., SQL, ODBC), 3) leading products are interchangeable, 4) vendors compete on extended or niche capabilities, and 5) vendors don't compete on software price. I'd further add that with a commodity there is no barrier to user entry-level adoption - ten minutes with a broadband Web connection will net you a no-cost, fully functional copy of MySQL or a PostgreSQL variant or an “express” version of any leading closed-source RDBMS - and there's similarly only a low entry barrier for a would-be technology provider.

However, if you need an enterprise DBMS that will scale to 100 TB and 5,000 simultaneous users with extreme uptime etc., then your choices are vastly reduced. The same applies to other sets of particular requirements. The RDBMS vendors therefore differentiate via extras, via their branding, tools, extensions, solutions, alliances with service providers and integrators, packaging in suites and stacks, association with particular operating systems/platforms, and services.

Understanding market maturity and vendor market positioning can help you make better choices, both at an architectural level and in surveying and selecting from among choices where the differences that matter may be quite small. It is important to assess each vendor's differentiation points and decide if they are truly relevant to your needs. Exploit the commodity status of the core RDBMS functions in order to license and pay for only the extras that you really need.

I plan to look at Business Intelligence as a commodity software technology in a subsequent article.