If there’s one central theme to my blog DBMS2, it’s that modern DBMS alternatives should in many cases be used instead of the traditional market leaders. So it was only a matter of time before somebody sponsored a white paper on that subject. The paper, sponsored by EnterpriseDB, is now posted along with my other recent white papers. Its abstract is reproduced below. Its conclusion — also summarizing what kinds of database management system you should use when — may also be found on DBMS2.
General-purpose relational database management systems -- such as Oracle - are great products. They form the underpinnings to most of the world's transactional applications, most of the world's data warehouses, and many more specialized systems as well. Their versatility is truly amazing.
But the same maturity and versatility that make the leaders so impressive also cause them to be complex, cumbersome, and locked into design choices that aren't ideal today. And so, for ever more use cases, there are superior alternatives. Specialty data warehouse DBMS, running on cost-effective MPP (Massively Parallel Processing) systems, far outperform the SMP-bound (Symmetric MultiProcessing) market leaders. While the leaders support native text search and XML processing, specialist products far outdo them in relevance and speed. And if you want a stripped-down, embeddable database running on a single-purpose electronic device, Oracle and SQL Server are far from the best alternatives.
Even where general-purpose DBMS do a great job, market-share leading products may not be the best choice. For 20 years, there have been simpler and less expensive alternatives, including reseller-oriented products (such as Progress or Informix SE), Microsoft SQL Server (before it grew up), or open source DBMS such as MySQL and PostgreSQL. These mid-range products' initial appeal is often just price - they cost less to buy than the alternatives, or perhaps even can be had for free. An even greater cost advantage, however, can come in ongoing administration - because they're newer and simpler, mid-range DBMS are often much easier to administer than their high-end brethren.
For more and more transactional applications, mid-range DBMS do everything that is needed. Hot standby/failover? 24/7 operation? Triggers, stored procedures, and declarative referential integrity? Datatype extensibility? Draw up your OLTP feature checklist, and one or more mid-range DBMS are apt to meet it. Leading commercial products still are ahead in super-high-end scenarios, whether the need is extreme throughput, many-9s bullet-proofing, or advanced security certifications. But except for those edge cases, mid-range DBMS can meet just about any need.
Actually, there's one big exception - portability from existing DBMS. Startups aside, almost every enterprise has a rich portfolio of database applications, and porting them to a new DBMS is a daunting task. But even here there's been major progress. EnterpriseDB offers robust Oracle compatibility. Other vendors - especially but not only in data warehousing -- have portability/transparency offerings as well.
These developments add up to a classic "disruption" scenario, as the term is used in Clayton Christensen's The Innovator's Dilemma. Startup DBMS vendors are exploiting new markets (e.g., Web 2.0), technical strategies (e.g., data warehouse appliances), and business models (e.g., open source). Traditional leaders continue to innovate magnificently, but in ways that matter to fewer and fewer users (mainly, the largest enterprises running the biggest transactional apps). And the cheaper, simpler upstarts are maturing until they're suitable for ever-larger fractions of the overall market.
So is it time to move away from your current market-leading DBMS products? Yes and no. Reasons not to move include in-house skills, quantity-discount contracts, applications that would be difficult to port, or third-party applications that don't run on upstarts' products at all. But for many new applications, the TCO advantages of newer DBMS are so compelling that a switch is called for. And in increasingly many cases, even existing applications are better off moved.