Document database
A database that stores whole nested JSON records instead of flat rows spread across tables. One document holds the object and its children.
See it
What it is
A document database stores whole nested records (JSON or BSON) as single units. Instead of an order row plus five line-item rows plus an address row stitched together by joins, one document holds the order and everything hanging off it. Records live in collections, and two documents in the same collection can have different fields. MongoDB, Firestore, CouchDB, and DynamoDB (loosely) play here; Postgres jsonb columns blur the line so much that 'relational or document' is now a per-column decision, not a per-project one.
Reach for it when the shape genuinely varies per record (form responses, CMS blocks, third-party webhook payloads, event bodies), when you always read the whole object at once, or when you are moving fast and the shape is still changing weekly. Reads are one lookup, no join planning, and the record comes back looking exactly like the object in your code.
Gotcha: 'schemaless' means nothing enforces a schema by default, not that there is no schema. There is one, it lives in your application code, and unless you make it explicit at both ends every read has to cope with documents written by three older versions of your app. Make it explicit: these databases can enforce shape if you ask (Mongo's $jsonSchema validators, Firestore security rules), and you parse on read with something like Zod on top. Stamp each document with the version of the shape it was written in, so old ones get upgraded on read rather than guessed at. Second trap: embedded arrays that grow forever (comments on a post) eventually hit document size limits and turn every read into a big read.
Ask AI for it
Model this feature as a document database collection instead of relational tables. Design one document per aggregate, embedding data that is always read together and referencing by id anything shared or unbounded. Include a 'schemaVersion' field on every document. Define one Zod schema per supported version plus an explicit upcaster chain (v1 to v2, v2 to v3) that converts an old document into the current shape before the current schema validates it, since a version field and a parse call do not migrate anything on their own. Write the upgraded document back after a successful conversion where the read path can afford a write. Enforce the current shape at the database too with a $jsonSchema validator, and add indexes for the exact query patterns I listed (not one per field). Show the document shape as a TypeScript type plus one example document with real values.