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.

The Trade-Offs NoSQL Databases Make

NoSQL databases generally trade some of the strict consistency and complex query flexibility that relational databases provide in exchange for horizontal scalability and flexible schemas — a tradeoff formalized in the CAP theorem, which states a distributed database can’t simultaneously guarantee full Consistency, Availability, and Partition tolerance, forcing a deliberate choice about which to prioritize. Different NoSQL database types make this trade-off differently: document databases like MongoDB prioritize flexible schemas for rapidly evolving application data models, key-value stores like DynamoDB prioritize extreme scalability and low-latency access patterns, and wide-column stores like Cassandra prioritize write throughput and multi-region availability, meaning “NoSQL” isn’t a single alternative to relational databases but an umbrella term covering several genuinely different architectural approaches suited to different problems.