This paper examines SQL and NoSQL data stores designed to scale simple OLTP-style applications across many servers. These systems, originally inspired by Web 2.0 applications, are designed to handle thousands or millions of users performing updates and reads, unlike traditional DBMSs and data warehouses. They contrast on data models, consistency, storage, durability, availability, query support, and other dimensions, often sacrificing some dimensions (e.g., ACID consistency) for others (e.g., higher availability and scalability). NoSQL systems typically have six key features: horizontal scalability, replication, simple interfaces, weaker concurrency, efficient storage, and dynamic attributes. They range from simple distributed hashing (e.g., memcached) to highly scalable partitioned tables (e.g., Google's BigTable). These systems often use "shared nothing" horizontal scaling, allowing high throughput for simple operations. They generally do not provide ACID transactions, instead using "BASE" properties (basically available, soft state, eventually consistent) in contrast to ACID (atomicity, consistency, isolation, durability). The paper compares key-value stores (e.g., Voldemort, Riak, Redis, Scalaris, Tokyo Cabinet, Memcached), document stores (e.g., SimpleDB, CouchDB, MongoDB, Terrastore), extensible record stores (e.g., HBase, HyperTable, Cassandra), and scalable relational systems (e.g., MySQL Cluster, VoltDB, Clustrix, ScaleDB, ScaleBase, NimbusDB). Key-value stores support insert, delete, and lookup operations, with varying levels of replication and consistency. Document stores support nested documents and multiple types of documents, but lack ACID transactions. Extensible record stores are inspired by BigTable, with row and column partitioning. Scalable relational systems offer SQL and ACID transactions but may sacrifice performance for scalability. The paper concludes that NoSQL systems offer high scalability and availability but sacrifice consistency, while scalable relational systems provide ACID transactions but may not scale as well. Both approaches have trade-offs, and the choice depends on application requirements.This paper examines SQL and NoSQL data stores designed to scale simple OLTP-style applications across many servers. These systems, originally inspired by Web 2.0 applications, are designed to handle thousands or millions of users performing updates and reads, unlike traditional DBMSs and data warehouses. They contrast on data models, consistency, storage, durability, availability, query support, and other dimensions, often sacrificing some dimensions (e.g., ACID consistency) for others (e.g., higher availability and scalability). NoSQL systems typically have six key features: horizontal scalability, replication, simple interfaces, weaker concurrency, efficient storage, and dynamic attributes. They range from simple distributed hashing (e.g., memcached) to highly scalable partitioned tables (e.g., Google's BigTable). These systems often use "shared nothing" horizontal scaling, allowing high throughput for simple operations. They generally do not provide ACID transactions, instead using "BASE" properties (basically available, soft state, eventually consistent) in contrast to ACID (atomicity, consistency, isolation, durability). The paper compares key-value stores (e.g., Voldemort, Riak, Redis, Scalaris, Tokyo Cabinet, Memcached), document stores (e.g., SimpleDB, CouchDB, MongoDB, Terrastore), extensible record stores (e.g., HBase, HyperTable, Cassandra), and scalable relational systems (e.g., MySQL Cluster, VoltDB, Clustrix, ScaleDB, ScaleBase, NimbusDB). Key-value stores support insert, delete, and lookup operations, with varying levels of replication and consistency. Document stores support nested documents and multiple types of documents, but lack ACID transactions. Extensible record stores are inspired by BigTable, with row and column partitioning. Scalable relational systems offer SQL and ACID transactions but may sacrifice performance for scalability. The paper concludes that NoSQL systems offer high scalability and availability but sacrifice consistency, while scalable relational systems provide ACID transactions but may not scale as well. Both approaches have trade-offs, and the choice depends on application requirements.