Are Proprietary Databases Doomed?

Times of change are upon the database market. The major established database companies are being challenged by open source upstarts like MySQL and PostgreSQL. For years, Open Source Databases (OSDBs) have been quietly increasing their penetration, but until recently they have lacked the capabilities to seriously threaten proprietary databases like Oracle, IBM's DB2, and Microsoft's SQL Server.

All that has changed. OSDBs now boast the necessary features and robustness to support commercial databases hundreds of Gigabytes in size. And a growing trickle of competitive benchmark results shows them performing more than acceptably well against their better-established cousins, while offering significant benefits in Total Cost of Ownership (TCO).

What does this mean for proprietary databases? Are they doomed? And more importantly, are there opportunities for end users to benefit from the rise of OSDBs? I will explore these topics in a multi-part blog:

  1. Feature Stagnation In The Traditional Database Market
  2. License Costs: the Soft Underbelly of Proprietary Databases
  3. The Looming Open Source Database Tsunami
  4. The Perfect Storm for Proprietary Databases
  5. Proprietary Counter Strategies
  6. Conclusion
The standard disclaimer applies as always: these are my opinions and not necessarily those of Sun or anyone else.

1. Feature Stagnation In The Traditional Database Market

When I joined Sun in the late 80s, choosing a database was still an important issue for end users. Large customers routinely issued tenders for databases as well as for computer systems, and, to help in the selection process, customers often staged performance bakeoffs between competing database vendors using home-grown benchmarks.

In the 90s, fierce competition led to a rapid explosion in features as well as dramatic improvements in performance. Sun in particular invested a lot of engineering effort in working with the major database companies to improve performance and scalability. At the same time, a variety of new technologies appeared, many claiming they would knock the relational database from its throne. Distributed databases, object relational, shared nothing, and in-memory database implementations all made cameo appearances. Relational databases simply absorbed their best features and continued to rule. Simple database features like triggers and stored procedures gave way to more sophisticated technologies like replication, online backup, and cluster support.

By the turn of the millenium, relational databases had already pretty much met the essential requirements of end users, and proprietary database companies were either pointing their vaccuum cleaners toward other interesting money piles, or losing the plot entirely and sailing off the edge of the world. Today, database releases continue to tout new features, but they're frosting on the cake rather than essentials. No-one issues a tender for a database unless they have unusual requirements. No-one loses their job because they chose the wrong database. And it's been that way for years.

Put very simply, the database has arguably become a commodity.

2. License Costs: the Soft Underbelly of Proprietary Databases

Databases may have become commodities, but selling them is still very profitable. Historically, as CPU performance increased with faster clock speeds, users continued to pay the same price for database licenses on the newer, more powerful systems. But that all changed as the industry moved to multi-core CPUs. As we will see, the licensing policies adopted by proprietary database companies have ensured that license charges have increased steeply as a result of this revolution in processor chip technology.

Some years ago, chip manufacturers began turning to multi-core CPU designs as a way of continuing to drive improvements in CPU performance. As it becomes more difficult to increase the transistor density of CPU chips and increase clock speeds, multi-core chips offer a simple alternative by packing more than one core on a single chip running at a lower clock speed. At the same time, proprietary database vendors began basing license charges on the number of cores in a system.

A practical example is Sun's dual-core UltraSPARC-IV chip. It replaced the single-core UltraSPARC-III chip at the same clock speed. By delivering two cores instead of one, the UltraSPARC-IV offered twice the performance of its predecessor. A typical system was the popular UltraSPARC-IV-based Sun Fire V490 which included four dual-core chips (eight cores). This system replaced the Sun Fire V480 with four single-core UltraSPARC-III chips. The customer received twice the CPU performance for the same hardware price.

Not so for the Oracle database price, though. Based on per-core licensing, the new system was now treated as an 8-core system instead of a 4-core system as previously. And worse, users were forced to a significantly more expensive database edition if they deployed systems with more than four cores. So, compared to the V480, the V490 now attracted a much higher per-core charge, on top of the requirement to pay for twice as many core licenses.

The following table illustrates the extraordinary windfall received by Oracle:

Relative Performance1.02.0
Relative Hardware Price1.01.0
Database Core Licenses Required48
Relative Core License Price1.02.7
Relative Database License Price1.05.3

In the face of considerable pushback from the industry, Oracle responded with "discounts" for the second core in a chip. In the case of the V490, that meant the discounted database price was still four times the license charge for the V480!

So while users continued to enjoy more powerful and more feature-rich hardware at the same or lower price, they were paying a lot more to use the same database software on the new hardware.

The situation prompted comments like those from Stephen Elliot, an enterprise systems analyst at IDC, who anticipated increased pressure on Oracle to be more flexible with pricing, and reported that "Oracle is becoming the lone force on the processor issue". Since that time, under pressure from Microsoft, which introduced per-chip database licensing back in Feb 2005, Oracle has continued to tweak its licensing model, but so far without making wholesale changes.

It should be noted that Oracle is not alone in following this path - similar anomalies apply to the pricing of IBM's DB2 database. Nor is Microsoft the only vendor to embrace a per-chip pricing strategy - as long ago as 2005, the Register reported that BEA was adopting the same per-socket licensing model as Microsoft and VMware, and noted that "the software maker's move puts it in prime fighting position against Oracle and IBM, which have been slow to adjust their pricing models for new chips from AMD, Intel and others." According to Ashlee Vance in July 2007, "Most software vendors have had the decency to settle on a per-socket basis for their pricing schemes, ignoring the number of cores per chip. Meanwhile, IBM and Oracle, the vendors with the most to lose, prefer to keep you in a state of pricing confusion."

Anecdotally, some companies are finding that database licenses have become their single biggest IT cost. The impact is probably greater on small and medium-sized companies that don't have the same ability to command the hefty discounts that larger companies typically enjoy from database vendors. A colleague related a story that illustrates the issue. His brother worked for a 200-person company that decided it was time to upgrade their database applications. They set out to deploy a well-known proprietary database until they discovered that the database license fee was going to exceed their entire current annual IT budget! They ended up deploying an open source database instead.

3. The Looming Open Source Database Tsunami

In August 2007, Tom Daly revealed the results of a SPECjAppServer2004 benchmark based on an entirely open source software stack, with PostgreSQL running on a Sun Fire T2000 server and the Glassfish Application Server on two Sun Fire X4200 servers. The announcement was revealing for two reasons:
  • It showed PostgreSQL capable of supporting more than 6,000 concurrent users on a commodity hardware platform
  • The benchmark result was within 10% of a published result from an HP/Oracle configuration costing more than three times as much. The major reason for the huge price difference was the cost of Oracle (at $110,000 compared to PostgreSQL $0).

    For the record, it should be noted that the SPECjAppServer2004 benchmark does not include a pricing metric, so these are not official prices. Nonetheless, since benchmark configurations clearly cost actual money, it seems reasonable to assess the prices involved. In this case, all hardware and software prices were drawn from publicly-available sources.

Open source databases still do not scale as well as proprietary databases, but they now perform well enough to manage a broad range of challenging applications. End users who previously saw OSDBs as primarily suitable for simple low-volume applications are now able to reasonably consider them for departmental database server deployments.

Do OSDBs have the features needed for serious deployment, though? 12 months ago, Forrester Research released a report suggesting that eighty percent of applications typically only use 30 per cent of the features found in commercial databases, and that the open source databases deliver those features today. While Forrester noted that OSDBs still lag for mission critical applications, those holes are likely to be plugged as bigger players announce 24x7 technical support and service (as has already happened, for example, with PostgreSQL).

A recent survey of Oracle users showed 20% having open source databases larger than 50 Gbytes and two thirds citing cost as the driver to adoption of open source. Open source database adoption is still relatively small. Does that mean OSDBs should be dismissed? Not according to a Gartner analyst, quoted last year as saying "We think it is a big deal. Granted, in the DBS market right now, they are very small players. Remember about 10 years ago, Linux in the market was a very small player? Not so much, anymore."

The comparison may be apt. With the combination of essential features, improved performance, robust support, and compelling price, OSDBs today bear a striking resemblence to Linux a few years ago. Many believe that the wave looming on the horizon is a tsunami. Time alone will tell.

4. The Perfect Storm for Proprietary Databases

Underneath major end-user applications like ERP and data warehouse software, every major hardware and software component is now subject to commodity pricing. As we have seen, each year hardware prices continue to decline while processing power increases. At the same time, leading operating systems like Sun's Solaris and Linux are now open source and can be deployed for free. The same is true of most other components of the software stack, including virtualization software, databases, application servers, web servers, and other middleware. Even Sun's UltraSPARC T1 and T2 chips and RTL have been open sourced, allowing community members to build on proven hardware at a much lower cost.

Why, then, is proprietary database software becoming more expensive while everything else reduces in price? End users normally expect to benefit from the cost savings resulting from improvements in technology. I am writing this blog, for example, on an affordable computer that would easily outperform expensive commercial systems from just 10 years ago.

It seems difficult to resist the conclusion that proprietary database companies have managed to redirect a good chunk of these savings away from end users and into their own coffers. Successful as this strategy has been, though, it could ultimately backfire. The more expensive proprietary databases become, the more attractive lower cost alternatives appear.

A number of forces are currently at work in the market:

  • The momentum around open source software has continued to build, and many open source products, while not as capable as proprietary alternatives, have become "good enough" to replace them. This is also true of open source databases.
  • Large technology suppliers are beginning to bundle OSDBs, with the result that customers are able to take out support contracts with established companies as well as startups. Sun, for example, ships and supports PostgreSQL.
  • Benchmarks are beginning to feature OSDBs. Thus OSDBs are starting down a path that has been trod by proprietary databases over many years. Benchmarks can be expected to highlight the capabilities of OSDBs, accelerate the process of OSDB performance improvement, and, increasingly, expose the price difference between OSDBs and proprietary databases. And as the scalability of OSDBs increases, benchmarks will be published on larger systems, opening up an even wider gap in database pricing.
  • The sweet spot in the hardware market is a two- to four-chip server. With the advent of quad-core chips from Intel and AMD, and the 8-core UltraSPARC T1 and T2 chips released by Sun, such systems have become powerful enough to carry out processing that required much larger and more expensive systems in the past. The pricing chasm between low cost hardware and high cost proprietary databases continues to widen.

    For example, the UltraSPARC T1-based servers, the Sun Fire T1000 and T2000, shipped with 8 cores on a single chip. The recently-released single-chip, 8-core UltraSPARC T2 servers, which deliver twice the performance at roughly the same cost, now attract a DB2 license charge that has increased 66% compared to the T1 platforms. So IBM has taken the opportunity to significantly hike the price of the database software on that platform, even though the number of chips and number of cores has not changed.

    At the same time, 8-core UltraSPARC T1 servers attracted a 2-core license charge from Oracle (a very reasonable pricing decision on Oracle's part - see this table which is referenced from here). At the time of writing, Oracle has not announced a final decision on pricing for the T2 platform, but it is unlikely that Oracle will be able to resist the temptation to emulate or even outdo the cynicism of IBM. Why such a pessimistic expectation? Because the same table referred to above announces that the 1.4GHz UltraSPARC version of the older T1 servers will be subject to a 0.5 multiplier instead of the 0.25 multiplier that applies to the 1.0 GHz and 1.2 GHz versions of the same platform. So a simple 17% clock speed increase in the hardware, with no other changes at all, prompted Oracle to double the license charge!

    To be fair to Oracle, since the UltraSPARC T1 and T2 platforms are single chip systems, customers can purchase Standard Edition and Standard Edition One licenses for them at greatly reduced prices. But these editions do not offer the full Oracle feature set, and in particular they do not offer the parallel processing capabilities essential for efficient processing on the 32-way T1 and 64-way T2 platforms; if customers want parallel capabilities they must purchase the vastly more expensive Enterprise Edition with its core-based licensing and inexplicable and inconsistent "discounts".

  • Web 2.0 is gathering momentum, and the new breed of companies leading the charge are largely ignoring proprietary databases for their deployments. Probably much of the scepticism relates to the cost implications.

In the past there has been no real alternative to proprietary databases. That has changed, at least for new applications that have no legacy database dependencies. The relative proportion of hardware and software purchase prices has been changing, too, and for some years software has gradually been consuming ever-larger slices of the pie. In recent times the pace has accelerated, though, as commodity-priced hardware has become much more powerful and database prices have increased.

For the most part, customers still have not entirely woken up to these trends. But if they ever do, we may see a significant shift in the database market. Is it possible that the perfect storm for proprietary databases is brewing?

5. Proprietary Counter Strategies

Proprietary Database companies are not without ways of responding to the challenge from OSDBs. Here are a few possibilities.
  • Strategy 1: Resistance is Futile - You Will Be Assimilated. Picking off your competitors can get a lot easier when they are open source companies, because most of them struggle to address a major discrepancy between their penetration and their annual revenue. Putting it another way, they have plenty of users but very little revenue to show for it. Hey, their product is free, after all! So far, not many people have figured out how to become absurdly rich by giving away software.

    Buying a competitor gives you access to their Intellectual Property (IP) and their customer base. Sometimes it simply eliminates a competitor from the marketplace. Either way, playing the Borg can be an effective way of reshaping the market in your favor.

    Note that Oracle has already made some raids across the border, having acquired InnoBase, maker of InnoDB, MySQL's most popular transactional engine, and Sleepycat Software, maker of Berkeley DB, another transactional engine used with MySQL. In response, MySQL has scrambled to introduce Falcon, a transactional database engine of its own.

    Any of the major proprietary database companies could reasonably play the role of the Borg in this scenario, though, since all of them have very deep pockets. MySQL is probably the most vulnerable to takeover, since it's privately held. PostgreSQL may be more difficult to silence, since it is developed by an active community rather than a single company. But in either case, even if you pick off the company or the key community contributors, you haven't removed the IP from the market because the database is open source.

  • Strategy 2: Bait And Switch. Offer a cut-down version of your own proprietary database for free, primarily targeting developers and companies doing pilot implementations. The idea is to make it easy for people to develop on your platform, then charge like wounded bulls when they deploy in earnest.

    All of the major proprietary databases have free cut-down versions. Oracle Lite supports databases limited to 4 Gbytes of disk and 64 concurrent connections. Microsoft's Sql Server Express Edition supports one CPU only, 1 Gbyte of memory, and 4 Gbytes of disk. IBM's DB2 Express-C supports 2 processor cores, 2 Gbytes of memory, and unlimited disk.

    These database editions are free, but they are not open source. The pricing policy could change overnight. And, as outlined above, each has restrictions that limit their usefulness for deployment.

  • Strategy 3: Revenue Pull-Through. Include the database as a bundle with other pieces of your software stack. Focus the customer's attention on buying something else, and chances are they won't notice or won't care that they've bought your database as well.

  • Strategy 4: Business As Usual. If you wait long enough, perhaps open source databases will stumble or be acquired by someone. Maybe their fall will be as meteoric as their rise. Or maybe the Borg will show up and assimilate them before they build too much more momentum. Either way, it will be one less competitor to worry about.

    If you think a wait-and-see strategy sounds implausible, history shows that when they can't make up their minds how to respond, a lot of companies (and countries for that matter) do little more than sit on their hands. Australia's first ice skating gold medalist, Steven Bradbury, demonstrated how to win this way in spectacular fashion at the 2002 Winter Olympics. (Actually the last comparison is not entirely fair to Steven Bradbury - although he did win because the other contestants all stumbled, Bradbury's presence in the final was an achievement in itself that clearly demonstrated his ability and commitment.)

  • Strategy 5: Reduce Prices. Much of the imperative for a migration to OSDBs will be removed if proprietary database companies drop their prices significantly. The excellence of proprietary databases is certainly not under question - I can personally attest to the performance, scalability, rich feature set, and robustness of both Oracle and DB2, for example. The search for alternative databases is largely driven by the need for pricing relief. OPEC discovered in the 1970s that inflated oil prices led to both energy conservation and a search for alternative energy sources. When OPEC soon reduced prices again, much of the impetus behind alternative energy disappeared in the West (sadly).

    This strategy is only feasible if proprietary database companies derive most of their revenue from other sources. Oracle is probably the most vulnerable here.

My vote for the Strategy Most Likely To Succeed is a tie between Revenue Pull-Through and Reduce Prices. Oracle is arguably becoming the most successful proponent of the pull-through strategy. Oracle wants to supply you with a full software stack, including an OS, virtualization software, a broad range of middleware, a database, and end user applications. The largest component of Oracle's revenue currently still comes from database licenses, but the company is working hard to reduce that dependency. Until that happens, reducing prices across the board will be challenging for Oracle. If Oracle succeeds with a pull-through strategy, it doesn't mean that OSDBs will fail, of course. It simply means that Oracle is less likely to sustain major damage from their success.

Price reductions, if they are large enough and sustained enough, are likely to do more to slow down OSDB penetration. But I suspect that proprietary companies, if they are to do it at all, will need to reduce prices soon; if enough momentum builds around OSDBs we will reach a tipping point where it won't matter any more (witness the rise of Linux).

6. Conclusion

Are proprietary databases doomed, then? Not at all. Even if proprietary database companies pull no surprises, they won't fade away anytime soon. Too much legacy application software currently depends on them. Until ISV applications - like SAP's R/3, for example - support MySQL and PostgreSQL, end users will be wedded to proprietary databases. (Note, though, that SAP does support its own free and open source MaxDB database with R/3). As Oracle builds its software portfolio, too, more applications will ship with the Oracle database bundled. And for the forseeable future, proprietary databases will be the platform of choice for the largest mission-critical database deployments.

Make no mistake, though, open source databases are coming. For established companies it's more likely to be an evolution than a revolution. We will probably see a gradual OSDB surround, where new applications and deployments are increasingly based on OSDBs, driven by the cost savings. In emerging markets, though, it's looking more like a revolution. Last year I met with a small number of high-adrenaline companies in India, a market undergoing very rapid growth. They were openly dismissive of proprietary databases. One company had a small installation that was described as a "legacy" application due for replacement by an open source database. This is the scenario playing out today at high fliers like Google, Facebook, YouTube, and Flickr.

How can you take advantage of the rise of OSDBs? Here are some suggestions:

  • If you're considering a new database deployment, examine the possible cost savings of an OSDB.
  • If you're an established proprietary database user, don't simply throw out your database. Take the time to establish the feasibility and quantify the benefits of an OSDB solution before making a change.
  • If you're unhappy about the prices you're paying for database software, let your supplier know - the more senior the contact, the better. Suppliers do listen to their customers! As a side note, if you're a proprietary database customer looking at OSDBs, you don't need to make a big secret of it. I know of situations where proprietary database suppliers offered deep discounts to keep a customer away from OSDBs!

Perhaps the last word should go to The Economist. The following observations, reported in January 2002, may well prove prescient: "if software firms continue to think they can cash in on every new increase in computer performance, they will only encourage more and more customers to defect. And today, unlike a decade ago, open-source software has become just too good to be ignored."


What do you think? Feel free to let me know at Allan.Packer@Sun.COM.


[Trackback] Allan Packer started a multi-article blog entry about his opinion regarding the RDBMS market:Are Proprietary Databases Doomed?. I looking forward to the next parts of it. I think, that relational databases will be a really different market in a few ...

Posted by on December 11, 2007 at 07:44 PM PST #

when are you gonna throw msde -> ms sql trick in the mix?

Posted by Michael B on December 12, 2007 at 09:29 PM PST #

I agree that licensing costs are a huge barrier, but then the big vendors almost all have free 'light' versions available for commercial use, so things are slowly changing there.

It's misleading to suggest that Oracle is 'proprietary' and that MySQL isn't. Both are - both have proprietary extensions to standards like SQL. Being free and open source doesn't make you any less proprietary.

MySQL and PostgreSQL have been around for ten years. They've actually accomplished remarkably little in that time, just like the commercial vendors. Databases seem to be rather slow-moving beasts. I don't think anything in the RDBMS world is going to happen fast.

Posted by Jon on December 12, 2007 at 10:08 PM PST #

I'm the IT Infrastructure, Database Engineering Manager for a Large HMO and we are well into the process of replacing Proprietary Database Technologies from Oracle and MS SQL Server.

I brought My SQL Trainers in house to train my DBA staff on all aspects of My SQL and it was a great investment.

We are saving Thousands of dollars in licensing & support fees already as we replace existing Databases with My SQL and will be saving in the Hundreds of Thousands of Dollars within the next year as we replace core proprietary databases with My SQL.

-Dave Dragon

Posted by Dave Dragon on December 12, 2007 at 11:24 PM PST #

You know, there are database systems that \*aren't\* relational right?

Posted by Rudolf Olah on December 12, 2007 at 11:55 PM PST #


"Databases seem to be rather slow-moving beasts. I don't think anything in the RDBMS world is going to happen fast."

You are absolutely correct. A lot of people have wondered why the "OSDB Tsunami" is taking so long to swamp the industry. It's because the average business keeps mission-critical RDBMSes for five to ten years. This means that even if 50% of companies decided to replace proprietary databases with OSDBs \*today\*, we wouldn't see the effects on actual adoption until at 2012.

The database employment market is similar. In order to get a job as a full-time DBA, you are expected to have five years of experience. So the candidates who are on the market now reflect which databases were popular 5 years ago.

All of this means that the replacement of PDBs with OSDBs will take a decade to complete, even if there are no unexpected diversions.

Posted by Josh Berkus on December 13, 2007 at 01:27 AM PST #

Josh: Perhaps, but if so then momentum will be key, and now is the time to establish momentum in one direction or the other.

Posted by Nico on December 13, 2007 at 06:41 AM PST #

Jon, you suggest that MySQL is as proprietary as Oracle, because MySQL has extensions to the SQL standard. That isn't the normal definition of "proprietary", though. Wikipedia has this to say: "Proprietary software is software with restrictions on copying and modifying as enforced by the proprietor" (see By this definition, Oracle is proprietary and MySQL is not.


Posted by Allan Packer on December 13, 2007 at 10:25 AM PST #

Rudolph, as you noted, there are database systems that are not relational. But I'm focussing on relational databases in this blog, since they have dominated the market for many years.


Posted by Allan Packer on December 13, 2007 at 10:28 AM PST #

"A lot of people have wondered why the "OSDB Tsunami" is taking so long to swamp the industry."

Really simply answer on this, Quality, Flexibility and performance. I am sorry to say OSDB's in lot of cases a long way behind commercial offerings. And also in performance in many many cases.

Posted by John Cisco on December 13, 2007 at 12:34 PM PST #

Dave, thanks for sharing your story. Your experience illustrates the potential savings that can come from deploying open source databases provided the transition is well planned and carefully executed.


Posted by Allan Packer on December 13, 2007 at 01:07 PM PST #

License cost isn't everything. As someone who was responsible for a technical system with PostgreSQL at its heart it took me an extraordinary effort to find any DBA resources. If we had used Oracle or SQL Server I would have been able to engage one of maybe a dozen consulting companies to help out.

From a risk management point of view the potential cost to the organisation (of a failure without appropriate supporting staff) was immense and really did outweigh any potential license and support cost.

Posted by Andy Todd on December 13, 2007 at 02:06 PM PST #

For Decision Support workloads there is more than OSDB lurking out there to challenge the major proprietary DBMS's. The new columnar oriented, shared-nothing DBMS's such as ParAccel and EXAsol might be upstarts in this segment. Check out the latest TPC-H results for these databases. Also ParAccell has introduced a pricing model based on database size that might be advatageous for high thread count architectures.

Posted by Vince Carbone on December 14, 2007 at 01:48 AM PST #


So, you didn't go to
and talk to any of the over 100 consulting companies listed there?

Posted by Andrew on December 14, 2007 at 03:25 AM PST #

For those who don't believe the Open Source databases will come: people would not believe that WordPerfect would vanish...
It will certainly not go that fast, but we'd better be prepared for the fact that OSDB's will become increasingly popular.

@Andy: I did check Yes, there may be over 100 of them, but did you check out who they are? Many of them are small firms (less than 30 staff, most even less than 10), and many of them are just "dedicated to Open Source", rather than "specialized in "PostgreSQL".
And as for my situation (Europe, The Netherlands), only very few firms provide Dutch speaking staff, many do provide English speaking staff, but many companies are in Eastern Europe, so quite a chance that their English will consist of Yes, No, OK or "I don't understand you" I am afraid...
Surely, OSDB's will come, but wide business acceptance will take tens of years I guess.

Posted by Jan-Hendrik on December 16, 2007 at 05:20 PM PST #


Great article!

I had a few thoughts after reading your article:

1) Open source has expanded the database market. The surge in database use we have seen has come from the existence of open source databases. When you can easily install a database, the push toward "let us make this work with flat files" goes away. There are more users of databases today then there was a decade ago. Open Source databases have been a boon to companies like Oracle because they have extended the market. It has also forced Oracle and others to become more user friendly. The reason Oracle has been able to keep prices where they are at, is because the market has expanded.

2) SAP R3 already uses an open source database, MaxDB.

3) MySQL is no more held by the actions of others then any other open source database. Innodb is GPL. The only harm that can come is through neglect of the maintainers.

4) SQLite has commoditized the entire low end of the database market out of existence. If Apple had to pay a license fee for a database do you think they would have included a database as the back store for many of its applications?

The "good enough" solution of open source databases fits well within the 80/20 rule. The 20%? I think the question anyone who is a top 20% user should be asking themselves right now is "am I really that rare?". Commoditizing does not only mean picking commodity software, it is finding common solutions to problems. Less optimization, more use of common designs.


Posted by Brian Aker on December 17, 2007 at 06:03 AM PST #

[Trackback] Two interesting stories on concurrency came past my browser this morning: NYTimes on Microsoft's concurrency efforts and Allan Packer from Sun on open source databases. The NYT piece is about Microsoft's efforts to produce multicore programming tools, ...

Posted by O'Reilly Radar on December 17, 2007 at 06:50 AM PST #

You just got (indirectly) linked to from Groklaw,


Posted by David Collier-Brown on December 18, 2007 at 02:06 AM PST #

I read your article with interest. You raise some excellent points, but I fail to see how the miss-steps of the large proprietary source vendors necessarily points to the success of open source databases.
As far as I can see, there is nothing preventing a proprietary source vendor from seizing on the same weaknesses you mentioned and offering a better alternative. There are proprietary source database vendors that offer solutions that are much more competitive (on cost and other factors) with Open Source databases like MySQL than the big 3 (I work for one of them).

Posted by Jason on December 18, 2007 at 02:57 AM PST #

[Trackback] Your story has been submitted to! Come and promote your article by voting for it <a href="">here on FSDaily</a>! Let your readers know they can vote for your story too.

Posted by on December 18, 2007 at 11:02 AM PST #

Your article is interesting, but I feel that it discounted two concerns:
1) Standards. Some customers care about standards adherence and certification.
2) Proprietary. Regardless of Wikipedia's definition of proprietary, the fact remains that if one database has features that I use and all the others do not, I will be locked in to that vendor. Oracle or MySQL, it doesn't matter. This goes back to why standards exist in the first place.

Of course, the vendors know this, and eagerly lead you to use their product's unique features. Which is why the vendors want you to buy their entire application stack -- it will use every lock-in trick they have.

And if the standards are silent on a feature that you need, you will be locked in unless multiple vendors implement the same feature.

Which is why some vendors have insane price increases: they know the pain of moving from their lock-in is just slightly more than the pain of their increase. Which is one of the reasons why OSDB adoption is slow.

As OSDBs become more feature-compatible with their proprietary counterparts, the cot of adoption will go down, and thus the rate will increase.

Posted by Dave on December 19, 2007 at 07:19 AM PST #

I just received a pointer to an interesting and insightful piece published back
in Jan 2005 by Craig James, looking at the role of Free Open-Source Software in
the software lifecycle. Long, but well worth a visit. You can find it at


Posted by Allan Packer on December 21, 2007 at 12:10 PM PST #

PR foreva.
Sun foreva.

Posted by ЕНГ on December 22, 2007 at 01:16 AM PST #

"First they laugh at you, then they fight you, then you Win..." Ghandi
Oracle is expanding and increasing dependencies on their cash cow. They will continue to laugh for a good bit of time. DBA's are as religious about the database as coders can be about OS'es.

But, hopefully management gets a clue to the ridiculous margins of 10g

Posted by McD on December 24, 2007 at 05:51 AM PST #

The "legacy" proprietary databases still scale better and have capabilities that OSDBs lack. A significant example is Oracle's read consistency, which it has had for a long time and which is lacking in the OSDBs.

Posted by Dave on January 07, 2008 at 11:31 AM PST #

Post a Comment:
Comments are closed for this entry.

I'm a Principal Engineer in the Performance Technologies group at Sun. My current role is team lead for the MySQL Performance & Scalability Project.


« July 2016