TIODATANative knowledge database
Data is queryable the moment it is written, and the kernel keeps compiling it into knowledge: entities, facts and relations carry evidence, lineage and confidence. SQL, OLAP, document, full-text, vector, relational and knowledge queries share one executor and one policy. A Rust kernel on open Parquet / Arrow files: unified data infrastructure for AI agents.
Enterprise data is split across five or six systems
Reports run on the warehouse, search on a search engine, semantics on a vector store, relationships on a graph database and knowledge on RAG or a wiki. Every extra system adds a copy, a permission model and a definition that no longer matches — and AI agents are left stitching answers from fragments.
The same order lives in the warehouse, search index, vector store and graph, each updated on its own schedule.
SQL has row and column policies, but vector search and agent calls often bypass them.
Chunk-and-prompt answers cannot say which table, document or version a conclusion came from.
Ingestion waits for embedding and queries wait for compilation, leaving an offline pipeline between data and use.
A knowledge database: queryable on write, knowledge compiled continuously
Data becomes an immutable, queryable snapshot the moment it lands. The knowledge compiler turns it into entities, facts, relations and evidence in the background, without ever blocking queries or writes.
Not a graph database, vector store or RAG
The difference is not whether there are nodes or vectors, but what the system treats as first-class and where facts come from.
| Graph DB | Vector / search | RAG / LLM wiki | TIODATA | |
|---|---|---|---|---|
| First-class object | Node / Edge | Vector / document | Chunk / page | Data Object · Semantic Object · Data File |
| OLAP aggregation | Weak | No | No | Columnar, vectorized execution |
| Where relations come from | Hand-built edges | None | Model extraction | Compiled, with evidence, lineage and confidence |
| Policy | In-graph only | Often bypassed | Often bypassed | One policy for SQL and agents |
| Traceable knowledge | Partial | No | Weak | Every fact traces to a snapshot and source record |
One Data Object, three views
Data is never forced into a single database shape. The same object can be aggregated as a table, traversed as a semantic network and used as a source of facts for AI.
- Data View
- Tables and columnar files: standard SQL and OLAP aggregation with vectorized execution and pruning.
- Semantic View
- Entities and relations: customer → order → product → invoice, with bounded expansion and path queries.
- AI View
- Agents ask questions: semantics, vectors, evidence and aggregation answer together, with a source for every claim.
- Why have this customer's orders dropped recently?
- Orders fell 38% over the last 90 days, mostly in the B series. Two invoices were paid late in the same period, and service tickets show more complaints about delivery lead time.
- sales_order · snapshot #1042
- invoice · record #238812
- service ticket document · paragraph 3
| order_id | customer | product | amount |
|---|---|---|---|
| SO-1042 | Customer A | B-200 | ¥128,400 |
| SO-1043 | Customer A | B-310 | ¥86,900 |
| SO-1051 | Customer C | A-120 | ¥42,300 |
| SO-1056 | Customer B | B-200 | ¥63,750 |
Five core principles
Every engineering decision in TIODATA is held to these five statements.
“Store data in one place, express semantics once, compile knowledge continuously, enforce policy uniformly, execute queries in one engine.”
“Ingestion never waits for AI, queries never wait for compilation, compilation never blocks IO.”
“Models understand, the compiler constrains, the validator judges, the DataSpace keeps the facts.”
“Core dependencies are protocols, not products.”
“Full capability from 4 cores and 8 GB; grow by adding hardware and workers, not by switching databases.”
One query language, seven kinds of access
Every request goes through one AST, one policy layer and one executor. SQL, MySQL-protocol clients and agents all receive the same governed result.
- $ tioctl doctor
- [ok] storage [ok] meta [ok] policy [ok] knowledge [ok] index
- $ tioctl import csv ./sales_order.csv --collection sales_order
- snapshot #1042 committed · DATA_READY
- $ mysql -P 3307 -e "SELECT product, SUM(amount) FROM sales_order GROUP BY 1"
- B-200 192150.00 B-310 86900.00 A-120 42300.00
- $ tio query "RELATED customer:'Customer A' DEPTH 2 WITH EVIDENCE"
- Customer A → SalesOrder(2) → Invoice(2) → Payment(1) evidence: 5
Agents are first-class citizens
Not an agent framework wrapped around a database, but agent identity, capability and actions built into the kernel's policy and audit.
Each agent has its own identity and capability declaration; policy decides what it can see and do.
A structured interface for agents that returns results together with evidence and confidence.
Write actions go through Action + Approval, and every operation is audited.
DataSpace capabilities are exposed to external agents and developer tools via MCP.
Rust kernel, open files, one binary
Core dependencies are protocols only: storage, metadata, execution, full-text, vectors and models plug in through interfaces, with specific products as adapters.
- A single tiod binary runs as all-in-one, meta, coordinator, query or knowledge node
- Data is stored in open Parquet / Arrow formats, never locked into a private format
- MySQL protocol access lets existing BI and client tools connect directly
- Pluggable model runtime: OCR, embedding and LLMs assembled on demand
Roadmap
TIODATA is currently a technology preview and can be deployed and demonstrated in lab environments.
Explore the native knowledge database
DataHub provides a mature lakehouse and governance platform today; TIODATA is our next step toward AI-native data infrastructure. Book a technical session to see a demo and discuss collaboration.