NoSQL Database

What is NoSQL?

NoSQL is an umbrella for databases that abandon parts of the relational model to gain something else — usually horizontal scalability or schema flexibility. The main families: document (MongoDB, Firestore — JSON-shaped records), key-value (DynamoDB, Redis — fast lookups by key), wide-column (Cassandra — massive write throughput), and graph (Neo4j — relationship traversal). Vector databases are the newest member.

The honest decision rule

Default to Postgres. Modern relational databases handle JSON columns, millions of rows, and full-text search; most apps never outgrow them. Reach for NoSQL when you have a specific shape: known access patterns at extreme scale (DynamoDB’s sweet spot), caching and ephemeral state (Redis), write-heavy time-series/event firehoses (Cassandra), or genuine graph traversal. “Our schema might change” is not a reason — migrations are easier than living without joins.

What you give up

Joins (denormalize or join in app code), multi-record transactions (limited or absent), ad-hoc queries (many NoSQL stores require knowing your access patterns at design time — modeling DynamoDB tables around queries is the whole discipline), and strict consistency by default (see replication for why reads can be stale).

Cost reality

Managed NoSQL bills by throughput and storage (DynamoDB’s read/write units) — brilliant for spiky traffic with on-demand mode, but table scans and hot partition keys turn into eye-watering line items. Relational costs are boring and predictable by instance size; NoSQL costs mirror your access patterns, for better and worse.

What people get wrong

• Choosing NoSQL for scale you don’t have. A $50/month Postgres instance serves more traffic than most startups ever see.
• Treating a document DB relationally. If every query fans out into five lookups replacing joins, the model is wrong for the workload.
• Ignoring the consistency model. “Read your own write” isn’t guaranteed everywhere; discover this in design, not in a bug report.