NoSQL (Not Only SQL)
NoSQL, meaning 'Not Only SQL,' refers to a broad class of database management systems that differ from traditional relational databases by not primarily usin...
NoSQL ('Not Only SQL') databases represent a diverse category of database management systems that differ from traditional relational (SQL) databases in their data models and query mechanisms. They were developed to address the limitations of relational databases in handling large volumes of rapidly changing, unstructured or semi-structured data, and to provide greater scalability and flexibility. Common NoSQL data models include key-value stores (e.g., Redis, DynamoDB), document databases (e.g., MongoDB, Couchbase), column-family stores (e.g., Cassandra, HBase), and graph databases (e.g., Neo4j, Amazon Neptune). Key-value stores offer simple, high-performance retrieval based on a unique key. Document databases store data in flexible, JSON-like documents, allowing for schema evolution. Column-family stores optimize for reads and writes across large datasets by organizing data into columns rather than rows. Graph databases excel at representing and querying complex relationships between entities. NoSQL databases often prioritize availability and partition tolerance over strict consistency (following the CAP theorem), offering tunable consistency levels. They typically scale horizontally by adding more commodity servers, unlike the vertical scaling often required for relational databases. Trade-offs include the lack of standardized query languages across all types, potential for data redundancy, and challenges in performing complex joins or transactions that are standard in SQL.
graph LR
Center["NoSQL (Not Only SQL)"]:::main
Pre_data_structures["data-structures"]:::pre --> Center
click Pre_data_structures "/terms/data-structures"
Pre_distributed_systems["distributed-systems"]:::pre --> Center
click Pre_distributed_systems "/terms/distributed-systems"
Rel_relational_databases["relational-databases"]:::related -.-> Center
click Rel_relational_databases "/terms/relational-databases"
Rel_big_data["big-data"]:::related -.-> Center
click Rel_big_data "/terms/big-data"
Rel_vector_database["vector-database"]:::related -.-> Center
click Rel_vector_database "/terms/vector-database"
classDef main fill:#7c3aed,stroke:#8b5cf6,stroke-width:2px,color:white,font-weight:bold,rx:5,ry:5;
classDef pre fill:#0f172a,stroke:#3b82f6,color:#94a3b8,rx:5,ry:5;
classDef child fill:#0f172a,stroke:#10b981,color:#94a3b8,rx:5,ry:5;
classDef related fill:#0f172a,stroke:#8b5cf6,stroke-dasharray: 5 5,color:#94a3b8,rx:5,ry:5;
linkStyle default stroke:#4b5563,stroke-width:2px;
🧒 Explain Like I'm 5
NoSQL databases are like different kinds of storage boxes for computer information. Instead of just one way to organize everything like in a filing cabinet ([SQL](/en/terms/sql)), you can use special boxes for different needs, like a big bin for lots of similar items or a special binder for connected notes.
🤓 Expert Deep Dive
NoSQL databases diverge significantly from the ACID (Atomicity, Consistency, Isolation, Durability) properties typically guaranteed by relational databases, often embracing BASE (Basically Available, Soft state, Eventually consistent) principles, particularly in distributed systems prioritizing availability and partition tolerance (AP systems in CAP theorem). Key-value stores leverage hash tables or similar structures for O(1) average-case lookups. Document databases use formats like BSON or JSON, allowing for nested structures and dynamic schemas, often indexed for efficient querying. Column-family stores (wide-column stores) partition data by row key and then group related columns into column families, optimizing for queries that access specific column subsets across many rows. Graph databases use nodes, edges, and properties, with traversal algorithms optimized for relationship exploration. Architectural trade-offs center on the CAP theorem: choosing between Consistency and Availability in the presence of network partitions. Scalability is typically achieved via sharding and replication. Vulnerabilities can arise from insecure default configurations, lack of robust transaction support, and potential data inconsistencies if not managed carefully.