The Aberdeen Group looks at free databases [LWN.net]

The Aberdeen Group has put together an "analyst report" on free databases, as typified by MySQL, PostgreSQL, and Berkeley DB. The report is available for download, in PDF format, from the SleepyCat site, but one must get through a moderately obnoxious registration screen first. For those who don't want to do that, here's a quick summary.

The report starts with a set of reasons why free databases are of interest; they include control over maintenance and support, source availability, cost, flexibility, and reliability. A quick summary of the three covered systems follows, with the "key features" which are supported or missing. The report summarizes the situation in this way:

All of today's open source databases are seen today as lacking especially in scalability, and to a lesser extent in robustness, flexibility, and programmer support. Therefore, they are not classified as "enterprise." Many are clearly deficient in at least the first three aforementioned technologies - they do not offer (or offer limited) stored procedures, do not offer two-phase commit, and do not offer exceptional multiprocessing support.

The free database systems have reached "enterprise" levels of scalability and robustness, however.

The free database market, says Aberdeen, is currently worth about $100 million per year - compared to $10.5 billion for the proprietary variety. Free databases have mostly been making inroads at the low end of the market (the report doesn't say this, but that is how disruptive technologies usually get their start). Aberdeen mentions several times in particular that free databases on Linux are displacing SCO installations. The biggest area for free databases, however, is "new in-house applications." Displacing entrenched systems in other applications is currently too hard, but new applications typically do not have legacy issues to deal with. The best markets for free databases have been in retail and telecommunications.

As for the future:

Over the next two years, the market will reach a "tipping point" at which a larger range of vertical application and line-of-business programmers will find open source databases' low cost and association with other open source software such as Linux a good reason to include open source databases in their plans. At that point, open source databases will begin to have a significant impact on the overall database market, on database pricing, and on the readiness of the market for an "enterprise-scale open source database."

The authors of the report talked with free database users, and found that those users are well pleased with the level of programming help and support available for the software. If you use a free database system, you can actually talk with the engineers who wrote it, which is not possible with large, proprietary systems. Thus, notes the report, if you're using a free database, you should expect to communicate with the development community, and not just with a vendor.

The talk of licensing is remarkably FUD-free:

Users should also note that open source licenses are different from proprietary ones. Users should understand the differences and then rejoice in the ease of maintenance of open source licenses, which do not require extensive administration.

The report concludes by saying that free database adoption will stay slow for the next couple of years before beginning to ramp up. The authors state the the lower-level programming tools offered with free database systems will slow down adoption somewhat. Over time, however, the advantages of free databases will lead to those systems having a "moderately bright" future.

(Log in to post comments)

The Aberdeen Group looks at free databases

Posted Mar 31, 2004 15:55 UTC (Wed) by tlewis (guest, #4195) [Link]

> Many (free databases) are clearly deficient in at least the first three
> aforementioned technologies - they do not offer (or offer limited) stored
> procedures, do not offer two-phase commit, and do not offer exceptional
> multiprocessing support

Uhh, postgresql has had two-phase commit and stored procedures for as long as I can remember. As for exceptional multiprocessing support, if they mean multi-threaded execution of single queries then they are right. I would be happy to leave that segment of the market to oracle and have the free db's take the rest. 8^)

PG has two-phase??

Posted Mar 31, 2004 20:11 UTC (Wed) by Baylink (guest, #755) [Link]

When did that happen? And does it only do it with itself?

The Aberdeen Group looks at free databases

Posted Mar 31, 2004 21:55 UTC (Wed) by cajal (subscriber, #4167) [Link]

PostgreSQL does not have two-phase commit. There has been some discussion on the developers list about how to implement it, but it is still in the discussion stage.

The Aberdeen Group looks at free databases

Posted Apr 1, 2004 10:55 UTC (Thu) by pointwood (guest, #2814) [Link]

OTOH, According to the Firebird Factsheet, it supports this: http://www.firebirdsql.org/ff/foundation/FBFactsheet.html

The Aberdeen Group looks at free databases

Posted Apr 1, 2004 17:05 UTC (Thu) by cajal (subscriber, #4167) [Link]

I agree entirely. I'm not sure where Aberdeen got their PostgreSQL info, but most of it wrong. They certainly didn't contact any of the PostgreSQL developers; many of them were quite... "amused" to read some of Aberdeen's claims.

For instance, Aberdeen claims that PG doesn't have deadlock detection (it does), doesn't support row-level locking (it does via SELECT FOR UPDATE, but you normally don't need it, thanks to multiversioning), and doesn't have updateable views (just use a RULE to get the update). The report also claims that "the next version of PostgreSQL may come as late as two years from now." I have no idea where that came from; if you look at the release notes, you'll see that PG has never taken more than a year to release a new version.

Atomic vs Two Phase

Posted Apr 1, 2004 0:54 UTC (Thu) by ccyoung (guest, #16340) [Link]

Apparently pg has atomic transactions, but not two phase. What is the difference? How important is it?

I wish they had aesthetic issues. IMHO things like different data types for text < 256 chars, < 1024 chars, etc, is plain butt ugly, as well as, for example, having to declare something a "blob" instead of "varchar" is you want case-sensitive comparison.

pg's pgpgsql is quite functional but a bit klutzy, but pg's internal procedures also suport pltcl, pltclu, plperl, plperlu, and plpython, so it's hard to fault that aspect.

Atomic vs Two Phase

Posted Apr 1, 2004 2:23 UTC (Thu) by stephenjudd (guest, #3227) [Link]

Here's an explanation of two phase commit.

It's pretty important if your transaction depends on a service outside your DBMS. Eg, think of an order process where the order only gets committed if there's authorisation from a third party. Anywhere with mixed legacy systems in the back end, such as your typical bank, probably would like two phase commit in the DB. It's distributed systems 101.

Like anything else, you can implement this in your application code instead, but it's nice when the DB does it for you, because it's harder to do right than you think.

Atomic vs Two Phase

Posted Apr 5, 2004 15:34 UTC (Mon) by rwmj (guest, #5474) [Link]

I wish they had aesthetic issues. IMHO things like different data types for text < 256 chars, < 1024 chars, etc, is plain butt ugly, [...]

Well, this is of course an area where PostgreSQL really wins. In PG I always use 'text' for strings of any length. I was horrified recently when doing an Oracle contract to find out that there's still no obvious way to have a string longer than 4000 chars!

Rich.