Monday Jun 27, 2016

Oracle Berkeley DB Java Edition 7.0 Announced

Oracle Berkeley DB Java Edition 7.0 is now available for download.

Download Page – Click Here

Documentation Page – Click Here

Oracle Berkeley DB Java Edition Version 7.0 – New Feature

· Time-To-Live – efficient aging out of “expired” data – This is a common IoT requirement.

Berkeley DB JE continues to enable the most powerful embedded database solutions

· Pure Java library

· Handle TBs of data with a small, lightweight, embedded library

· Flexible, transactional data management engine

· Runs on a variety of operating systems and platforms.

· Over 50 open source software projects embed BDB -- check them out on Wikipedia

· Various options for APIs

· Industrial quality and battle tested

Supporting Assets and Resources:

Collateral and sales assets continue to be updated.

· Oracle Berkeley DB Web Site

· Oracle Berkeley DB blog

· Oracle Berkeley DB Java Edition Datasheet

· Oracle Berkeley DB Family Datasheet

LinkedIn Group –

Twitter @berkeleydb

Community Berkeley DB –

Community for Berkeley DB Java Edition -

Blogs -

Tuesday May 31, 2016

Update for Oracle Berkeley DB - Version 6.1.29

Oracle is pleased to announce an update to Berkeley DB (BDB), version 6.1.29.  We want to make sure that some important features that are in our latest release (6.2.23) are available to those of you who continue to use the 6.1 release.

The highlights include:

  • A new utility db_convert which will convert a database to the endianness of the machine it is running on.
  • Encryption can be enabled when Binary Large Object (BLOB)  files are stored external to the database.
  • An improved vote comparison routine used to select a new master in HA.

Please go to :    to download this release, 6.1.29.

Check out the change log for details on all the changes in this 6.1.29 update release.  Click Here.

Monday May 16, 2016

Slices in BDB

Slices in Berkeley DB

(courtesy of Charles Koester) 

With the new Berkeley DB 6.2 release, there are a number of new features.  One of the more exciting ones is the use of Slices.

It is possible to improve the multiprocessor scaling of your DB databases by implementing slices. Slices cause your database records to be spread evenly across sub-environments and sub-databases using an internal hashing algorithm. Because your records are stored in separate physical environments and databases, this allows for better parallel processing support by spreading read and write workloads across separate, discrete processor cores.

The new “slices” feature can improve the multi threaded performance of IOT and many other workloads. Throughput in multi threaded applications can improve by 3x or more. Transactions which access a single key — e.g., solo DB->get(), DB->put, or DB->del() calls, or DB->get() followed by an update call — are ideal for the use of the slices feature.. Workloads in which related sets of keys are accessed inside a single transaction can also use slices. By using the new DB->set_slice_callback() API call to designate the slice-relevant portion of the key, a transaction can access many different keys as long as they share the slice callback value.

Read more about the new Slices feature in Berkeley DB at:

Monday May 02, 2016

Information on a new feature in Berkeley DB 6.2 - BDB Server

Information on a new feature in Berkeley DB 6.2 

(courtesy of Yong Li)

BDB Server (aka. BDB as standalone server or thrift)

Beyond being an industry-leading embedded key-value database, BDB Server turns BDB into a key-value database server which supports a client-server style of access. User applications can now use BDB Server client drivers to access remote BDB Servers.

Currently, the following BDB features are supported by BDB Server:

* B-Tree, Hash and Recno access methods.

* Transactions. (BDB Server can be run in Transaction Data Store mode only)

* Secondary indices and foreign constraints

* Join cursors

* Sequences

The following BDB features are not supported by BDB Server now:

* Queue and Heap access methods

* Replication

* Most call-back functions

The following features are specific to BDB Server:

* Support for SSL over TCP

* Handle timeout. If a handle has not been access for a long time, it can be closed automatically by the server.

System requirement for BDB Server:

* JDK 8 or above

Currently BDB Server client drivers are only available in Java and require JDK 8 or above. The Java client driver API is very similar to the BDB Java API with a few functions to open and close server connections.

Get Berkeley DB version 6.2 at:

Monday Apr 25, 2016

Greatly Improved SQL Index Performance for Oracle Berkeley Database, Version 6.2

A new whitepaper has been published, "Greatly Improved SQL Index Performance for Oracle Berkeley Database, Version 6.2". Learn how to increase the performance of SQL Queries using BDB.

Go to:     and look at the Whitepaper section. 

Tuesday Feb 02, 2016

New Version of Berkeley DB Java Edition - 6.4.25

A new version of Oracle Berkeley DB Java Edition is available that should be downloaded, Version 6.4.25.  Numerous bugs have been fixed and Oracle highly recommends that users and developers download this latest release. Click Here to go to the download page.

Monday Jul 14, 2014

Berkeley DB 12cR1 ( released

New Releases of Oracle Berkeley DB

Available For Download Now
Release Update

The newest release of Berkeley DB 12cR1 ( is available now. Here is a summary of the new features:

      upgrades to in-memory OLTP throughput & performance
HA improvement to identify a single master in a 2 site replication group
HA useability improvements
new Blob support added into replication
removed need for fail check monitor process
reduced the time for a database backup
and a lot more!

Berkeley DB continues to enable the most powerful embedded database solutions

      Handle TBs of data with a 1MB library
Flexible, lightweight storage engine, small footprint
Runs on low power ARM devices to cluster of high-end servers
Over 50 open source software projects embed BDB -- check them out on Wikipedia
Completely customizable, choose from 5 different access methods
Industrial quality and battle tested with over 200 million deployments

BDB is hands-down the best edge, mobile, and embedded database available to developers.  With the flexibility to place log files and/or database in any directory, applications can easily take advantage of the IO performance of flash caches, flash disks or SSDs.

Top notch performance

  • Berkeley DB performs over 5 million operations a second on a 100GB database running on a 1/8 rack Exadata V2 Database Machine configured with 256GB RAM and 12 cores.
  • Berkeley DB can insert 100 thousand records in 72 milliseconds and read those records in 30 milliseconds, running on a 8 core XEON-based commodity server.  The records contain a 4 byte key and a 48 byte data value.  This was run using the benchmark described on pages 34-36 in an ebook on SQL Server 2014 from Microsoft Press.
  • To put this into perspective, we compared Berkeley DB to SQL Server 2014's In-Memory OLTP feature (code name Hekaton)  which has similar technology.  Berkeley DB, an open source product, is about 20% faster than SQL Server 2014 which takes 94 milliseconds for the same 100k insert operations on an 8 core X64 Intel commodity box with 14 GB memory.

    We are making available a benchmark program in C that can be configured to validate Berkeley DB throughput for the 100K insert test here.

What folks are saying:

Open source Fedora package maintainer, Lubomir Rintel, says "Berkeley DB has quietly served behind the scenes as the database for the RPM Package Manager.   It has proven itself time and time again as a robust and efficient storage engine.   It stores the meta information of the installed rpms.  Under heavy workloads, BDB proves itself reliable. Countless people that use popular Linux distributions have used BDB through RPM and never knew it.  With this new release,   BDB continues its tradition of being a solid storage engine"

Oracle Tape Product Manager, Dan Deppen, says "Berkeley DB is integral to Oracle StorageTek Storage Archive Manager (SAM-QFS).  We have been embedding Berkeley DB in our product for over a decade and it is vital to our disk archiving feature which is used to send files to remote data centers to enable disaster recovery.  Performance and scalability are critical because SAM-QFS supports some of the largest archive customers in the world.   HPC sites, research centers, national libraries and other customers requiring massive scalability and high reliability depend on SAM-QFS and Berkeley DB to maintain availability of their critical data."

  Oracle Identity Management Vice President, Shirish Puranik, says "Berkeley DB is a critical component of Oracle Unified Directory (OUD) and Oracle Directory Server Enterprise Edition (ODSEE).  We have been using Berkeley DB in these products as a high performance, transaction embedded database repository for several years.  Berkeley DB has exceed our expectations for performance and stability. Our Berkeley DB based products are widely deployed in production at largest telcos and financial institutions all over the world.   The improvements for BLOB support and high availability in the 6.1 release are welcome."

Software Downloads


Please direct product questions to our Product Help Mail list for Berkeley DB. You can also email the Berkeley DB Product Management team directly.

Berkeley DB Product Management
Internal -

Thursday Jun 12, 2014

Data management in unexpected places

Data management in unexpected places

When you think of network switches, routers, firewall appliances, etc., it may not be obvious that at the heart of these kinds of solutions is an engine that can manage huge amounts of data at very high throughput with low latencies and high availability.

Consider a network router that is processing tens (or hundreds) of thousands of network packets per second. So what really happens inside a router? Packets are streaming in at the rate of tens of thousands per second. Each packet has multiple attributes, for example, a destination, associated SLAs etc. For each packet, the router has to determine the address of the next “hop” to the destination; it has to determine how to prioritize this packet. If it’s a high priority packet, then it has to be sent on its way before lower priority packets. As a consequence of prioritizing high priority packets, lower priority data packets may need to be temporarily stored (held back), but addressed fairly. If there are security or privacy requirements associated with the data packet, those have to be enforced. You probably need to keep track of statistics related to the packets processed (someone’s sure to ask). You have to do all this (and more) while preserving high availability i.e. if one of the processors in the router goes down, you have to have a way to continue processing without interruption (the customer won’t be happy with a “choppy” VoIP conversation, right?). And all this has to be achieved without ANY intervention from a human operator – the router is most likely to be in a remote location – it must JUST CONTINUE TO WORK CORRECTLY, even when bad things happen.

How is this implemented? As soon as a packet arrives, it is interpreted by the receiving software. The software decodes the packet headers in order to determine the destination, kind of packet (e.g. voice vs. data), SLAs associated with the “owner” of the packet etc. It looks up the internal database of “rules” of how to process this packet and handles the packet accordingly. The software might choose to hold on to the packet safely for some period of time, if it’s a low priority packet.

Ah – this sounds very much like a database problem. For each packet, you have to minimally

· Look up the most efficient next “hop” towards the destination. The “most efficient” next hop can change, depending on latency, availability etc.

· Look up the SLA and determine the priority of this packet (e.g. voice calls get priority over data ftp)

· Look up security information associated with this data packet. It may be necessary to retrieve the context for this network packet since a network packet is a small “slice” of a session. The context for the “header” packet needs to be stored in the router, in order to make this work.

· If the priority of the packet is low, then “store” the packet temporarily in the router until it is time to forward the packet to the next hop.

· Update various statistics about the packet.

In most cases, you have to do all this in the context of a single transaction. For example, you want to look up the forwarding address and perform the “send” in a single transaction so that the forwarding address doesn’t change while you’re sending the packet. So, how do you do all this?

Berkeley DB is a proven, reliable, high performance, highly available embeddable database, designed for exactly these kinds of usage scenarios. Berkeley DB is a robust, reliable, proven solution that is currently being used in these scenarios.

First and foremost, Berkeley DB (or BDB for short) is very very fast. It can process tens or hundreds of thousands of transactions per second. It can be used as a pure in-memory database, or as a disk-persistent database. BDB provides high availability – if one board in the router fails, the system can automatically failover to another board – no manual intervention required. BDB is self-administering – there’s no need for manual intervention in order to maintain a BDB application. No need to send a technician to a remote site in the middle of nowhere on a freezing winter day to perform maintenance operations.

BDB is used in over 200 million deployments worldwide for the past two decades for mission-critical applications such as the one described here. You have a choice of spending valuable resources to implement similar functionality, or, you could simply embed BDB in your application and off you go! I know what I’d do – choose BDB, so I can focus on my business problem. What will you do?


Information about Berkeley DB products directly from the people who build them.


« August 2016