A multimodal database gives an application more than one way to work with its data. In OriginChainDB, those ways are SQL, vector search, graph queries and full-text search.
Each answers a different kind of question. A price filter needs exact values. A search in everyday language needs relevant meaning. Finding connected records needs relationships.
First, what does “multimodal” mean?
The word has two uses that are easy to confuse:
- In AI: modalities usually mean types of input or output, such as text, images, audio and video.
- On the OriginChainDB website: multimodal describes four ways to query data. The broader database term for supporting several data models is multi-model.
A database supporting vector search does not, by itself, understand a photograph or transcribe a recording. Those tasks need an appropriate model or processing service. The database can store the resulting records and support retrieval.
Four ways to ask your data
| Query model | Use it to | Example question |
|---|---|---|
| SQL | Filter, join and calculate using structured fields. | Which guides were updated this month? |
| Vector | Find similar meaning using numerical representations called embeddings. | Which passages explain a device losing power? |
| Graph | Follow relationships between records. | Which guide belongs to this device model? |
| Full-text | Search indexed words and phrases. | Which passages mention error E42? |
These are complementary tools. You do not have to use all four for every request.
How the pieces stay connected
Start with a source record: for example, a guide with an ID, a title, a device model and its text. Searchable passages and relationships keep a reference to that record.
A search result can then lead back to the original guide. Your application can check the guide’s version, show the matching passage and explain which device it covers.
OriginChainDB provides the four query models in one database product. Setting up a table, creating search indexes and generating embeddings are separate parts of the implementation. A shared record ID connects their results; it does not automatically create every index or combine every query.
What changes for the application?
With separate database products, a team may need to copy records between systems and keep their identifiers, updates and permissions aligned. Using several query models in one database can reduce that integration work.
The application still needs a clear retrieval process. It decides which queries to run, how to combine results and which evidence to show. It must also handle an edited document or a missing relationship.
When is it useful?
- Knowledge search: match a question to a passage, then open its source.
- Recommendations: find related items and check their current availability.
- Investigation: start with a record and follow its links to other records.
- AI applications: give a model relevant text alongside exact facts and relationships.
If your application only needs a few tables and ordinary filters, SQL may be enough. Add another query model when there is a question your current approach does not answer well.
Where to start
Write down three questions your application must answer. Identify whether each needs exact fields, words, meaning or relationships. That small exercise tells you more than choosing a database from a feature list.
Explore OriginChainDB’s query models, then use the documentation to try the approach your application needs.