In this chapter
We'll meet multi-model databases as a real, existing category — PostgreSQL with pgvector, MongoDB's Atlas Search, Redis's document/search modules — genuine single systems natively supporting more than one data model, landing this Act's own core realization with real, named examples.
The Problem in Real Life
Sarah goes looking for a way to cut the number down, expecting to find nothing — surely a document database can't also do what a search engine does, or a graph database's job. She finds the opposite: several of the products GreenMart already evaluated turn out to genuinely do more than one of these jobs, in the same system, at once.
PostgreSQL, extended with pgvector — the exact real extension Act 9 already named — doesn't just do relational rows. It does vector similarity search too, in the same database, the same query, no second system involved.
It's not one database pretending to be several. It's actually several, for real, in one place.
Sarah
One Category, Strictly vs. Several Categories, Genuinely
Multiple real models, one real system
Not a workaround — a genuine product natively implementing more than one data model, queryable together.
pgvector is a real, already-met example
Relational/document storage plus genuine vector similarity search, same database, same query — Act 9's own closing chapter.
Several real combinations exist
Document + search, document + key-value, graph + relational — each a real, named product capability, not a hypothetical.
This directly answers last chapter's cost
One system genuinely doing two jobs is real operational weight given back — fewer logins, fewer places to keep in sync.
What a Multi-Model Database Offers
A multi-model database genuinely supports multiple data models in one system — not by faking one on top of another, but by actually implementing more than one real storage/query model natively, in the same product, queryable together. This isn't a hypothetical category; GreenMart has already met a real example of one, back in Act 9's own closing chapter.
- Document + key-value. Redis, mostly known this course as a pure key-value/data-structure store, also ships real document and search modules — the same underlying engine handling both jobs, not two separate products glued together.
- Document + vector. PostgreSQL with
pgvector— Act 9's own real example — combines relational/document-style storage with genuine vector similarity search, in the same database, the same query, no second system needed. - Document + search. MongoDB's own Atlas Search adds real full-text search capability directly onto its existing document storage — the exact document model Act 2 already taught, now also answering Act 7-style search queries natively.
- Graph + relational. Some relational databases (PostgreSQL again, via extensions; certain graph-capable engines) support genuine graph-style traversal queries alongside standard relational tables — Act 6's own traversal idea, available without a separate, dedicated graph product.
- Search + document, vector + document, and other real combinations each follow the same real shape: one product, more than one genuine underlying model, queryable together — not a marketing claim, a real, architectural fact about how that product is actually built.
Why multi-model systems exist follows directly from last chapter's own honest cost: if one real product can genuinely do two (or more) of the jobs eight separate specialized systems were each doing alone, that's real operational weight given back — fewer logins, fewer upgrade schedules, fewer places the same fact has to be kept in sync. This is precisely why GreenMart finding pgvector already sitting inside a database it might use anyway is a genuinely different situation than needing a whole separate, dedicated vector database.
Key Takeaway
Real systems don't always fit neatly into one database category. A multi-model database is the concrete proof of that sentence — not a workaround, a real product genuinely implementing more than one data model natively, letting a single system do what this course has, until now, always assumed needed a dedicated specialist.
Why This Matters
Every remaining chapter in this Act reasons about when this option is actually worth taking — a multi-model system solving two of GreenMart's eight problems at once doesn't automatically mean it should solve all eight, and the next chapter is about exactly what gets given up in exchange.
GreenMart now has real, correctly-named examples of single systems genuinely spanning more than one database category. What consolidating onto fewer systems actually costs — not just saves — is exactly where the next chapter goes.