At the time of writing, there were dozens of NoSQL database options available, both as standalone/local service installations and as cloud database options. The driving factors behind the designs of most of them include an emphasis on the following:

• Support for massive numbers of users: Tens of thousands of concurrent users, maybe millions—and supporting them should have as small a performance impact as possible
• High availability and reliability: Being able to interact with the data even if one or more database nodes were to go completely offline
• Supporting highly fluid data structures: Allowing structured data that isn't bound to a rigid data schema, perhaps even across records in the same data store collection

From a development perspective, the last point in this list is perhaps the most significant, allowing almost arbitrary data structures to be defined as needed.

If the concept of a table in a RDBMS is a storage model, there are a number of alternative storage models across the NoSQL database continuum:

• Document stores: Each record equivalent is a document containing whatever data structure it was created with. Documents are often JSON data structures, and as such allow for some differentiation between different data types—strings, numbers, and booleans as simple values, nested lists/arrays and objects for more complex data structures—and also allow for the use of a formal null value.

• Key/Value stores: Each record equivalent is simply a value, of whatever type, and is identified by a single unique key. This approach could be thought of as a database that is equivalent to a single Python dict structure.

• Wide column stores: Each record could be thought of as belonging to a RDBMS table with a very large (infinite?) number of columns available, perhaps with a primary key, or perhaps not.

There are also some variants that feel like they combine aspects of these basic models. Creating a data store in Amazon's DynamoDB, for example, starts by defining a table, which requires a key field to be defined, and allows a secondary key field to be defined as well. Once those have been created, though, the contents of those tables acts like a document store. The net result, then, act like a key/document store (a key/value store where each key points to a document).

NoSQL databases are typically non-relational, though there are exceptions to this. From a development perspective, this implies that one of at least three approaches needs to be taken into consideration when dealing with application data that is stored and retrieved from a NoSQL data store:

• Never use data that relates to other data—assure that every record contains everything it needs as a single entity. The trade-off here is that it will be difficult, if not impossible, to account for situations where a record (or the object that the record is associated with) is shared by two or more other records/objects. An example of that might be a user group that multiple users are a member of.
• Deal with the relationships between records in the code that works with those records. Using the same users/groups concept just mentioned, that might involve a Group object, reading all the relevant User records and populating a users property with User objects from that data during instantiation. There might be some risk of concurrent changes interfering with each other, but not significantly more than the same sort of process would risk in a RDBMS-backed system. This approach also implies that data will be organized by object type—a distinct collection of User object data and a distinct collection of Group object data, perhaps—but any mechanism that allows the different object types to be differentiated will work.
• Pick a backend data store engine that provides some sort of relational support.

NoSQL databases are also less likely to support transactions, though again there are options that do provide full ACID-compliant transaction capabilities, and the criteria/options for dealing with transactional requirements at the data store level are very similar to those mentioned previously, that is, dealing with relational capabilities. Even those without any transaction support are still going to be ACID-compliant for single records—at that level of complexity, all that is required to be compliant is that the record is successfully stored.