"NoSQL" is a somewhat unfortunate term that has been widely used to describe a class of database management systems that don't employ a relational data model. The terminology keys off the SQL query language - a hallmark of relational database management systems. Unfortunately the query language is not the real differentiator; in fact, it is not neccessarily a differentiator at all. Some "NoSQL" database management systems do, in fact, support the SQL query language! The fundamental difference in these systems lies not in the query language, but in the non-relational data model they employ. While "non-relational" database would be a more technically accurate term, it would also be more broad than the term "NoSQL" intends. It is interesting to note that a "backronym" has emerged in which NoSQL is proposed to stand for "Not Only SQL." While more accurate, it is even less descriptive.

NoSQL databases are characterized by their ability to store data without first requiring one to define a database schema. In Membase, data is stored as a distributed, associative array of Key-Value pairs, where the value is a "blob" of opaque binary data that doesn't conform to a rigid, pre-defined schema from the perspective of the database management system itself. Additionally, and largely enabled by their schema-less nature, these systems tend to support a "scale out" approach to growth, increasing data and I/O capacity by adding more servers to a cluster; and without requiring any change to application software. In contrast, relational database management systems "scale up" by adding more capacity (CPU, Memory and Disk) to a single server to accommodate growth.

Relational databases store information in relations which must be defined, or modified, before data can be stored. A relation is simply a table of rows, where each row (also known as a tuple) in a given relation has a fixed set of attributes (columns). These columns are consistent across each row in a relation. Relations (tables) can be further connected through cross-table references. One table, CITIZENS for example, could hold rows of all individual citizens residing in a town. Another table, PARENTS, could have rows consisting of PARENT, CHILD and RELATIONSHIP fields. The first two fields could be references to rows in the CITIZENS table while the third field describes the parental relationship between the persons in the first two fields (father, mother).