For the last few years, the world of NoSQL databases has been filled with exciting new projects, ambitious claims and plenty of chest beating. The hypesters said the new NoSQL software packages offered tremendous performance gains by tossing away all of the structure and paranoid triple-checking that database creators had lovingly added over the years.

Reliability? It's overrated, said the new programmers who didn't run serious business applications for Wall Street banks but trafficked in trivial, forgettable data about people's lives. Tabular structure? It's too hidebound and limiting. If we ignore these things, our databases will be free and insanely fast.

Alas, just as the summer of love ended and reality set in, the boundary-free experimentation with NoSQL databases is slowly being brought down to earth. Oracle, the developer of top notch bulletproof SQL databases, has arrived at the hippie fest with a solid, practical and very Oracle-like NoSQL server.

While the crazy dreamers can continue to craft NoSQL data stores, serious people will want to take a look at Oracle's version. It offers many of the features that make NoSQL fun, but also the solid performance promises that tend to come from big, serious teams of engineers. NoSQL pioneers will want to tell themselves that imitation is the sincerest form of flattery.

The arrival of this product might be a surprise to NoSQL fans who have listened to old school DBAs talk with pride about Oracle databases, but Oracle has been slowly moving down this path for some time. Five years ago, the company bought Sleepycat Software, the creators of the open source Berkeley DB, a tool with a long and rich tradition of flexible, key-value storage for C and lately Java programmers. This same Berkeley DB technology is said to be at the core of Oracle NoSQL Database, although it seems to be a complete rewrite.

Practically ACID

The fun part of Oracle NoSQL is the key-value structure. You don't need to define a schema or lock yourself into a big tabular architecture. You just create keys and attach a bag of bits to them. You might link your key to a string or an image file or anything. The database accepts the bytes and doesn't think much about the contents.

Oracle breaks up the key into major and minor parts. You can think of the major part as the object pointer and the minor part as the fields in the record. So you might put a name and Social Security number into the major parts of the key and other strings like the street address and ZIP code into the minor parts.

It's comparable to the way that some other NoSQL tools let you think of the value in the pair as being an object with multiple fields. Oracle just uses the term "minor key" for the names of the fields.

The serious part of Oracle NoSQL is a practical approximation of ACID compliance, the standard that SQL databases like to offer. ACID means "Atomic, Consistent, Isolated, Durable transactions," and there's a robust debate about just what this translates to in excruciating detail. Most NoSQL systems promise a different acronym, BASE, which stands for "Basically Available, Soft State and Eventually Consistent." In other words, you'll probably get the right answer except when you don't.

There will be plenty of debate about whether Oracle NoSQL offers real ACID compliance.

The promises aren't as all-encompassing as they are with SQL databases. You only get an ACID promise when you write data attached to the same major part of the key. For example, you could change the address and ZIP code of the same person and get an ACID guarantee because both parts are stored under the same major key. But you get no guarantee that changes to two separate people will remain consistent.

In other words, a bank could use Oracle NoSQL to store personnel records, but not to safely transfer cash between accounts because there's no ACID guarantee that the money won't get lost along the way.