In the crowded market of NoSQL databases, Couchbase Server is one of the dominant players. Its performance sets the bar high for its competitors. The rich feature set of Couchbase Server also sets a new standard for what is expected from NoSQL databases. As NoSQL is still a nascent field, Couchbase Server seems destined to influence its future.

All relational databases tend to be the same animal. Whether you're using SQL Server or MySQL, you could expect to find the same basic set of features. You store your data in rows with strictly defined columns inside a table. You then modify your data using SQL's INSERT and UPDATE statements. You retrieve your data using SQL queries. In contrast, NoSQL databases vary wildly from one system to the next. However, there are some features you would expect to find across various NoSQL taxonomies.

Perhaps the most common feature in NoSQL databases is the lack of an imposed structure on your data. While in practice, structures tend to be defined by your application layer, it is permissible that your NoSQL records are like snowflakes—no two records are the same. This flexibility has made NoSQL databases popular with developers, who no longer have to work within the constraints of a relational schema and ORMs.

Another feature (or lack of a feature) that you could expect to find in NoSQL databases is the lack of explicit ACID transactions. In other words, you won't be able to wrap a series of insertions or updates within a transaction. However, this does not mean that ACID properties are not supported in NoSQL databases.

Atomicity is widely supported in NoSQL databases. Partial writes are not possible. Either an entire record is written or nothing is written. Consistency in NoSQL ranges from eventual (delayed) consistency to strict consistency. Isolation is implicit, which means that a read will never return values from an update in progress. Like consistency, durability varies within NoSQL databases and is generally tunable.

The importance of full ACID compliance in NoSQL is somewhat diminished. Often, the need for transactions is dictated by the relational model, where related data is stored in one or more tables. In NoSQL databases, it is common to write related data to a single structure or record. In other words, a single NoSQL update or insertion might require several updates or inserts in the relational world.

This modeling difference also reduces the need for features such as joins or strict referential integrity. When records are stored in a denormalized fashion, a single query may bring back the required object graph.

Of course, it's likely that you will still need to make use of relational concepts in your NoSQL data model. Full denormalization is often impractical in NoSQL. In these cases, the applications that consume the data face an increased burden of being responsible for handling the details that a relational database typically would have dealt with.

Beyond these basic features, NoSQL systems tend to become more and more disparate. Instead, you will be more likely to find similar features between databases in the same NoSQL category. For example, CouchDB and MongoDB are both document stores. While they are fundamentally very different databases, they are more similar to each other than either of them is to a graph database such as Neo4j or a column database such as Cassandra. In the next section, I'll discuss the different categories of NoSQL databases and describe how Couchbase fits into the big picture.