What Is a Multi-Model Database? Keys, SQL, Graphs and Vectors Explained
A database is a way of keeping facts so you can find them again. The catch is that “find” means different things. Sometimes you know exactly which record you want. Sometimes you want every record that matches a condition. Sometimes you want whatever is connected to something you already have, or whatever means roughly the same as a sentence you just typed. Each of those questions has a shape of database built around it.
A multi-model database keeps more than one of those shapes in one place, over the same data. Here are the four that matter most for apps today, in plain terms, and what it costs to keep them together.
Key-Value: the Coat Check
You hand over a coat and get a ticket. Later, the ticket gets you the coat. That’s a key-value store: every record has a key, and the key takes you straight to it. It’s the fastest way to fetch one thing you can name, and it’s what sits behind caches, sessions and settings. On its own, it can’t answer “which coats are blue?”
SQL: the Spreadsheet You Can Question
Relational databases keep records as rows in tables, one column per field, and SQL lets you ask about them: the open orders over a hundred dollars from last month, grouped by country. It’s the workhorse of nearly every business app. It’s good with conditions and sums. It’s clumsy with chains of connections, and it can’t tell that “car” and “automobile” mean the same thing.
Graph: the Map of Who Knows Whom
A graph database stores links between records as first-class things: Dana owns this document, the document cites that one, that one was written by Sam. Questions follow the links. Everything within two steps of Dana. Every document that cites something she owns. Recommendations, fraud rings, org charts and knowledge graphs are graph questions at heart.
Vector: the Map of Meaning
An embedding model turns a piece of text, an image or a sound into a list of numbers, a vector, so that things with similar meaning land close together. “How do I reset my password” and “I forgot my login” end up near each other even though they share no words. A vector database stores those lists and answers “what is closest to this?” It’s how AI search and chatbots with access to company documents find what to read.
Why Apps End Up With Several
Real questions mix shapes. Find the documents most relevant to this question (vector), among the ones this customer can see (graph), that are still open (SQL). So teams run a relational database, add a vector database for search, and sometimes a graph database for relationships. Each copy of the data then has to follow every change in the others. When the copying lags or breaks, the answers disagree: search finds a document that was deleted, or skips one that was just added. Each database looks fine on its own. The bug lives in the copying between them.
A multi-model database closes that space. One copy of each record, reachable every way, changed in one transaction.
Big Engines and Small Files
There are two ways to get there. One is a large engine that does everything at scale: some are built for it from the start, and some are a general database with extensions bolted on, such as PostgreSQL with pgvector for vectors and recursive queries for graphs. They’re powerful, and they’re servers someone has to run and pay for.
The other is to stay small. HyperCrux keeps all four shapes in a single SQLite file, with the rules that tie them together stored in the file as triggers. Every record has a key, fields, links and an optional vector, and the four handles reach the same row. Vector search is exact: it compares every vector, so it never misses a closer match. That’s quick for thousands to around a hundred thousand vectors and slow beyond that, where an approximate index earns its complexity.
When One File Is Enough
A rough guide. If your data fits on one machine, most of your questions touch a few thousand to a hundred thousand records, and you’d rather not run three services to answer them, one file with four handles is the simple choice. If you have tens of millions of vectors, traffic spread across many servers, or graph queries that wander ten links deep through millions of connections, reach for the specialists.
The quick start shows all four handles on one small file, and one SQL query that uses them all at once.