01 SQL
Work with the facts.
Filter fields, join related tables and summarize records through the supported SQL interface.
- Works with
- Structured rows
- Returns
- Fields, rows and aggregates
Architecture
One engine.
Clear paths to your data.
Keep structured records, embeddings, relationships and searchable text in OriginChainDB. Choose the query path for each question, then use record IDs to bring the results together in your application.
Your applicationChoose a query
OriginChainDBOne engine
SQLFilter & summarize
VectorMatch by similarity
GraphFollow relationships
Full-textMatch words & phrases
Connected by record identityRetrieve the source. Build the response.
The query layer
Different questions.
Four ways to explore.
Each interface works with a different representation. A shared record ID keeps a match connected to its source.
02 Vector
Search by similarity.
Use a saved embedder on dedicated configurations or supply your own vectors. Keep dimensions consistent; metadata filtering depends on the selected index.
- Works with
- Embeddings + metadata
- Returns
- Record IDs and distances
03 Graph
Follow the connections.
Declare relationships between records, then explore neighbours, paths and supported graph patterns.
- Works with
- Records + declared relations
- Returns
- Connected IDs, paths or records
04 Full-text
Find the right words.
Index selected text fields and retrieve matching documents. Use the available search modes for words, phrases and ranked results.
- Works with
- Searchable text
- Returns
- Document IDs and scores
Supported queries and result shapes depend on the interface and configuration. Read the API reference for the exact request and response formats.
The write path
One identity.
Clear responsibilities.
Table indexes can follow your source rows. Choose configured embedding runs or explicit API writes for the other representations your application needs.
See explicit API writesReuse the record's identity across entries so a search result can lead back to the original fields.
-
Define the source record.
Register a schema, choose a primary key and save your rows. Configure table full-text indexes and declare the relationships you need; these follow row changes.
-
Choose how to produce embeddings.
On dedicated configurations, use a saved embedder and schedule runs for new or changed rows. Alternatively, generate vectors in your application and submit them through the vector API.
-
Coordinate explicit index writes.
If you supply vectors or use the separate document-index API, track those writes independently. Reconcile incomplete work and update or remove the explicit entries when their source changes.
Table full-text indexes and declared graph relations are maintained with row changes. Configured embedding runs prepare vectors separately. Explicit row, vector and document-index API calls commit separately and require coordinated updates and retries.
From matches to context
Find the evidence.
Keep the source in view.
A retrieval workflow can use several query paths. Your application decides which results matter and how to present them.
- 01Query interfaces
Find candidates
Run vector and full-text searches for similar meaning and matching words.
- 02Your application
Combine matches
Merge rankings and choose the record IDs relevant to the request.
- 03Records & graph
Retrieve context
Fetch source fields by ID. Follow declared relationships when more context helps.
- 04Your application
Build the response
Use the records in a search experience, a recommendation or an AI prompt.
Deployment & recovery
Understand the topology.
Plan for recovery.
Dedicated configurations run in your chosen region. Replication and backups serve different recovery needs.
Your selected regionDedicated
PrimaryOne active writer
Accepts writes while holding the writer lease.
Asynchronous replicationThe standby can trail the writer.
Optional standbyA follower in the same region
Replays changes received from the writer.
01
Know what a write confirms.
Check endpoint-specific durability and replication behaviour. A successful response is not a guarantee that the standby has received the change.
Write durability 02
Monitor before you promote.
Track replication lag and follow the promotion procedure. An abrupt primary loss can leave recent writes missing from the standby; promotion is operator-driven by default.
Deployment details 03
Practice restoring your data.
Daily snapshots provide a separate recovery path on dedicated configurations. Check the current archive and point-in-time recovery limitations before setting recovery targets.
Backup & restoreCross-region active-active replication is in development. Review topology and query limits when planning across nodes.
Build with OriginChainDB