Oracle Berkeley DB - $5,800.00 per processor
shop.oracle.com
shop.oracle.com
It's a dual license product. That price is only if you want to buy a commercial license distribute it with proprietary software to third parties. Their open source license allows you to use it on your server or in open source projects under a GPLish license.
BDB doesn't get near enough love as far as I'm concerned. It's crazy fast, and it's been around for two decades and it can scale to 256 Terabytes.
ref: http://www.oracle.com/technology/software/products/berkeley-... http://en.wikipedia.org/wiki/Berkeley_DB
The page you link to is carefully worded:
"The following are not redistribution: Building an application for use internal to your organization, deployed and managed on your company servers."
This does not appear to include using BDB on your public-facing web application.
I guess this is the final nail in the coffin for Berkeley DB, even though Tokyo Cabernet doesn't offer all the same features, the combination of Tokyo and better distributed systems like Cassandra/MongoDB are certainly pushing down into the market in which I would want to use BDB.
Distributed systems can be built upon BDB, we've had very good luck with using BerkeleyDB-Je in Voldemort. Many services within Yahoo and Amazon use custom distributed systems built upon BerkeleyDB. BerkeleyDB's own distribution, however, seems to just not be the right model for most people (HA "floating master" with Paxos elections). We (as did Amazon in the original Dynamo paper) found it easier to build their own replication, using BDB as one of the storage options.
Tokyo Tyrant is great if your data fits into memory. If it doesn't, performance declines without any grace (compare with BerkeleyDB where the performance remains reasonable with a 5:1 data:RAM ratio and surprisingly usable even with a 10:1 ratio).
That being said, there are some interesting alternative models e.g., Basho's bitcask, but it solves a different problem (purely K/V lookups vs. a B+Tree or -- with BDB-Je -- a log structured B+Tree).
I really wish there was a C/C++ based (at least until the Azul GC enhancements or the G1 collector become mainstream, making it possible to have a cache of over 10-15gb without pauses) log-structured B+Tree implementation... perhaps I'll get bored and write a toy one one day.
Now that the people who interpreted the license don't have control, and Oracle's lawyers do, I would not be entirely confident that the past interpretation of the license will necessarily be the future interpretation. The fact that I can't easily find anything documenting the old interpretation on Oracle's site does not give me comfort on this score.
For one thing, Oracle has always been good at imposing completely arbitrary 1000-column limits on databases that are probably scalable to far more. So with a really scalable database like Berkeley DB, just imagine what they can do!