Document Store
A store that keeps semi-structured documents — typically JSON — retrievable by key and queryable by their contents.
The model's strength is that a document can hold a whole aggregate: an order with its line items, addresses and status history in one record, fetched in one read with no joins. When the access pattern is "load this entire thing", that is both faster and simpler than assembling it from five tables.
Its weakness is the same property viewed differently. Data duplicated across documents has no constraint keeping it consistent, queries that cut across documents are expensive, and a schema that lives only in application code drifts silently between versions and between teams.
Two things that changed the calculus recently. Modern document stores added transactions across documents, so the classic "no multi-document atomicity" objection is weaker. And relational databases added strong JSON support with indexing on JSON paths — so Postgres can serve document workloads adequately, which for a system that also needs relational queries is frequently the better answer than running two stores.
Choose it when aggregates are the natural unit of access and their shape genuinely varies. Do not choose it to avoid designing a schema; the schema exists either way, and in a document store it is enforced by nothing.