Databases
NoSQL
A family of non-relational stores tuned for scale and flexible schemas — document (MongoDB), key-value (DynamoDB), wide-column (Cassandra) and graph (Neo4j). They scale out horizontally and suit unstructured or very high-write workloads. The trade-off is weaker consistency and joins pushed into application code, so you model around access patterns up front.
Purpose
NoSQL is an umbrella for non-relational stores built to scale horizontally and to store data whose shape varies: document stores (MongoDB), key-value (DynamoDB, Redis), wide-column (Cassandra) and graph (Neo4j). They emerged when web-scale write volumes outgrew what single-node relational databases could absorb.
When to Use It
Very high write throughput (events, telemetry), flexible or user-defined schemas, globally distributed low-latency access, and graph-shaped queries relational joins struggle with. Key-value stores also back caches and sessions almost universally.
If your data is relational and fits one beefy node — which is most applications — PostgreSQL remains the better default.
Trade-offs
You typically give up joins, multi-row transactions and strong consistency (many are eventually consistent by default), pushing that logic into application code. Data is modelled around access patterns up front — flexible to write, rigid to query in ways you did not plan for.
Implementation
Start from the queries, not the entities: design documents or key schemas so each access pattern is a single lookup. Denormalise deliberately and handle the resulting duplication on write. Understand the store's consistency knobs (read/write quorums, conditional writes) and its limits on item size and transactions before committing to it.