Rows, Documents, Vectors, Graphs, and Knowledge Objects: Where Does AIKOQL Fit?
In the first two posts of this series, I introduced why I started building AIKOQL and the idea behind the Knowledge Object.
But there is an obvious question that follows.
Why do we need another abstraction at all?
We already have relational databases.
We have document databases.
We have vector databases.
We have graph databases.
Each of these technologies solves important problems.
So where exactly does AIKOQL fit?
The short answer is:
AIKOQL is not trying to replace them.
The more interesting answer is that each database abstraction represents data differently because each was designed to solve a different class of problems.
AIKOQL is exploring whether AI systems introduce another set of requirements that existing abstractions do not always represent naturally.
To understand that, let's start with the abstractions we already use.
Different abstractions solve different problems
There is no universally perfect database model.
A relational database is excellent at some things.
A document database is excellent at others.
A vector database solves a different problem.
A graph database provides another perspective.
The mistake is assuming that one model should replace all the others.
Instead, we should ask:
What does each abstraction make easy?
And equally important:
What does each abstraction leave to the application layer?
1. Rows: structure, transactions, and consistency
Relational databases represent information as structured data.
For example:
Users
+----+--------+-------------------+
| ID | Name | Email |
+----+--------+-------------------+
| 1 | Alice | alice@example.com |
| 2 | Bob | bob@example.com |
+----+--------+-------------------+
This model is incredibly powerful.
Relational databases are excellent when you need:
Structured schemas
Strong consistency
Transactions
Constraints
SQL queries
Joins
Reliable business data
For a huge number of applications, a relational database is exactly the right choice.
But imagine asking the database:
Which information about this system is currently valid?
Or:
Which knowledge is supported by the most authoritative evidence?
Or:
What conclusions depend on this piece of information?
Those questions are not impossible to answer with relational databases.
You can build tables for provenance.
You can create temporal models.
You can store confidence scores.
You can create dependency relationships.
But these concepts are not necessarily first-class parts of the data abstraction.
The application has to define what they mean.
2. Documents: flexible and expressive information
Document databases take a different approach.
Instead of forcing information into fixed rows and columns, data can be represented as documents.
For example:
{
"service": "payments",
"database": {
"engine": "PostgreSQL",
"version": "16"
},
"owners": [
"platform-team"
]
}
This is useful for:
Flexible schemas
Nested data
Rapid application development
Semi-structured information
Evolving data models
Documents are a natural way to represent rich application data.
But a document still primarily answers:
What information was stored?
It does not automatically represent:
Whether the information is currently valid
Where each statement originated
What evidence supports it
Whether another source contradicts it
How authoritative the source is
What knowledge was derived from it
Again, these things can be added.
But they usually become application-level conventions.
3. Vectors: semantic similarity
Vector databases introduced another important capability.
Instead of retrieving information through exact values, vectors allow systems to retrieve information based on semantic similarity.
For example:
Query:
"How do I restart the payment service?"
↓
Vector Search
↓
Semantically Similar Documents
This changed how we build retrieval systems.
Vector search is particularly useful for:
Semantic search
Retrieval-Augmented Generation
Similarity search
Unstructured information
AI applications
But semantic similarity is not the same thing as knowledge.
Imagine two documents.
Document A:
"The production database runs on PostgreSQL."
Document B:
"The production database previously ran on PostgreSQL."
Semantically, these statements are very similar.
But temporally, they mean very different things.
A vector search may retrieve both.
The application or LLM must then determine:
Which one is current?
Now imagine another statement:
"According to the approved architecture decision, the production database now runs on CockroachDB."
This introduces another dimension.
The system must consider:
Semantic relevance
Temporal validity
Authority
Evidence
Knowledge state
Similarity alone is not enough.
This does not make vector databases less useful.
It simply means:
Similarity is one signal. Knowledge requires more context.
4. Graphs: relationships and connected information
Graph databases focus on relationships.
For example:
Service
│
├── DEPENDS_ON ────▶ Database
│
├── OWNED_BY ──────▶ Team
│
└── AFFECTED_BY ───▶ Incident
Graphs are extremely powerful when relationships are central to the problem.
They are useful for:
Relationship traversal
Network analysis
Knowledge graphs
Recommendations
Dependency analysis
Connected entities
Graphs answer an important question:
How are things connected?
But a relationship alone does not necessarily tell us:
Is this relationship still valid?
Where did it come from?
Who asserted it?
Is it verified?
Was it superseded?
What evidence supports it?
A graph can represent those concepts.
But once again, the meaning of those concepts often needs to be defined by the application.
The AI problem: combining multiple kinds of context
This is where the architecture of modern AI applications becomes interesting.
A typical AI system may look like this:
┌──────────────────┐
│ Relational DB │
│ │
└────────┬─────────┘
│
┌────────▼─────────┐
│ Document Store │
└────────┬─────────┘
│
┌────────▼─────────┐
│ Vector DB │
└────────┬─────────┘
│
┌────────▼─────────┐
│ Graph DB │
└────────┬─────────┘
│
▼
Application Logic
│
▼
AI / LLM Agent
The application becomes responsible for combining everything.
It decides:
Which database to query
Which results are relevant
Which information is current
Which source is authoritative
Which information should be trusted
Which relationships matter
Which historical information should be ignored
Which contradictions need to be resolved
The LLM then receives the final context.
This works.
But it raises a question:
Should all of this knowledge interpretation live outside the data layer?
That is one of the questions AIKOQL is exploring.
The Knowledge Object: adding meaning to information
AIKOQL introduces the idea of a Knowledge Object as a potential abstraction above raw information.
Conceptually:
Knowledge Object
Content
│
▼
+----------+
| Knowledge|
| Object |
+----------+
│
┌─────┼──────────────┐
│ │ │
▼ ▼ ▼
Provenance Time Relationships
Evidence State Derivation
Authority Confidence Lifecycle
A Knowledge Object is not defined only by its content.
It can also carry context about that content.
For example:
Knowledge:
"The production database runs on PostgreSQL."
Context:
Identity:
production.database.engine
Source:
Architecture Document
Authority:
Approved Architecture Decision
Evidence:
Infrastructure Configuration
Valid From:
January 2025
Valid Until:
June 2026
Current State:
Superseded
Superseded By:
knowledge-object-xyz
Now consider what an AI agent can ask.
Instead of:
Find documents mentioning PostgreSQL.
It could eventually ask:
What is the current production database?
The system now has the opportunity to consider:
Relevance
Time
Knowledge state
Authority
Evidence
That is the difference I am exploring.
AIKOQL is not another vector database
This is an important clarification.
AIKOQL is not trying to say:
"Vector search is obsolete."
Vector search remains extremely useful.
But vector search primarily helps answer:
What information is semantically related?
A Knowledge Object explores additional questions:
Is this information current?
Is it verified?
Where did it come from?
What supports it?
What contradicts it?
What knowledge was derived from it?
Can an AI agent reuse it?
Semantic retrieval can be part of a knowledge system.
But semantic retrieval alone does not define knowledge.
AIKOQL is not another graph database
Relationships are also important.
Knowledge Objects can have relationships.
For example:
Knowledge A
│
├── DERIVED_FROM ─────▶ Knowledge B
│
├── CONTRADICTS ──────▶ Knowledge C
│
└── SUPERSEDES ───────▶ Knowledge D
But AIKOQL is exploring relationships with additional meaning.
If Knowledge B becomes invalid, what happens to Knowledge A?
If Knowledge D was superseded, should the system return it as current knowledge?
If Knowledge C contradicts another verified statement, should both remain visible?
Relationships become operational.
They are not only used for traversal.
They can influence how knowledge is interpreted.
AIKOQL is not trying to replace relational databases
This is probably the most important point.
AIKOQL does not need to become the system of record for everything.
You should still use the best storage system for the workload.
For example:
Financial transactions
↓
Relational Database
Large analytical queries
↓
Columnar Database
Application documents
↓
Document Store
Semantic similarity
↓
Vector Search
Highly connected entities
↓
Graph Database
AIKOQL is exploring a different role.
Conceptually:
Existing Data Systems
│
┌───────────────┼───────────────┐
│ │ │
▼ ▼ ▼
Relational Documents Vectors
│ │ │
└───────────────┼───────────────┘
│
▼
Knowledge Layer
│
┌──────▼──────┐
│ AIKOQL │
│ │
│ Knowledge │
│ Objects │
└──────┬──────┘
│
┌──────────┼──────────┐
│ │ │
▼ ▼ ▼
Agents Retrieval Reasoning
This is the architectural space I find interesting.
AIKOQL does not necessarily need to replace the systems underneath.
It can explore becoming a knowledge-aware layer that gives AI systems richer context.
Where Knowledge Objects fit
The simplest way I currently think about the data ecosystem is this:
Rows answer:
What structured data do we have?
Documents answer:
What information was written or stored?
Vectors answer:
What information is semantically related?
Graphs answer:
How are entities connected?
Knowledge Objects explore:
What does this information mean in context?
And that context can include:
Identity
Provenance
Evidence
Authority
Epistemic state
Temporal validity
Relationships
Derivation
Lineage
Confidence
Lifecycle
This is the central hypothesis behind AIKOQL.
A different retrieval question
Traditional retrieval often looks like this:
Query
↓
Search
↓
Top K Results
↓
LLM
But a knowledge-aware system may eventually need something more like:
Query
↓
Semantic Relevance
+
Authority
+
Temporal Validity
+
Evidence
+
Knowledge State
+
Relationships
↓
Contextual Knowledge
↓
AI Agent
The difference is subtle but important.
The goal is not simply:
Retrieve the most similar information.
The goal becomes:
Retrieve the most relevant knowledge for this decision.
That may eventually require different signals depending on the workload.
A customer support agent might prioritize current information.
A research system might prioritize evidence.
A compliance system might prioritize provenance.
An autonomous agent might need to understand confidence and uncertainty.
This is why I don't think there will be one universal retrieval strategy.
The Knowledge Object can potentially provide the information required to make those decisions.
The role of AIKOQL in an existing architecture
One of the most important design principles for AIKOQL is interoperability.
AIKOQL should not assume that it owns all the data.
Real organizations already have:
PostgreSQL
MySQL
ClickHouse
Elasticsearch
Object storage
Data warehouses
Vector databases
APIs
Documents
Event streams
Replacing all of this infrastructure is unrealistic.
The more interesting problem is:
How can knowledge be built from information that already exists?
Conceptually:
Existing Data
│
▼
┌───────────────────┐
│ Relational Data │
├───────────────────┤
│ Documents │
├───────────────────┤
│ Files │
├───────────────────┤
│ APIs │
├───────────────────┤
│ Events │
└─────────┬─────────┘
│
▼
Knowledge Extraction
│
▼
Knowledge Objects
│
▼
Knowledge-Aware AI
That is a much more realistic position than claiming:
Move everything into AIKOQL.
The goal is to work with existing infrastructure.
Knowledge-aware does not mean knowledge is always correct
Another important distinction.
A Knowledge Object does not mean the system magically knows the truth.
Knowledge can be:
Incomplete
Conflicting
Outdated
Unverified
Inferred
Incorrect
AIKOQL is therefore exploring explicit knowledge state.
For example:
Observed
↓
Asserted
↓
Verified
Or:
Knowledge
├── Contradicted
│
├── Superseded
│
└── Invalidated
The goal is not to pretend uncertainty does not exist.
The goal is to make uncertainty visible.
For AI systems, this may be more important than storing another confidence score in a metadata field.
An AI agent should eventually be able to distinguish between:
"This is verified."
and:
"This was observed but has not been verified."
and:
"This information was previously valid but has been superseded."
Those distinctions are part of the Knowledge Object model.
From data to knowledge infrastructure
The direction I am currently exploring looks something like this:
DATA
│
▼
┌───────────────┐
│ Rows │
│ Documents │
│ Vectors │
│ Graphs │
└───────┬───────┘
│
▼
INFORMATION
│
▼
┌───────────────┐
│ AIKOQL │
│ │
│ Knowledge │
│ Objects │
└───────┬───────┘
│
▼
KNOWLEDGE
│
┌──────────┼──────────┐
│ │ │
▼ ▼ ▼
Retrieval Memory Reasoning
│ │ │
└──────────┼──────────┘
│
▼
AI Applications
This is not a finished architecture.
It is a direction.
And like everything else in AIKOQL, it needs to survive real implementation and testing.
Where I think AIKOQL can provide value
I currently see the strongest potential for AIKOQL in workloads where AI systems need more than retrieval.
For example:
AI Agents
Agents need persistent memory.
But memory is not simply a chat history.
An agent may need:
Facts
Observations
Experiences
Derived conclusions
Historical knowledge
A Knowledge Object can provide a structured way to represent these different categories.
Enterprise Knowledge Systems
Organizations have information spread across:
Documents
Wikis
Databases
APIs
Internal tools
AIKOQL is exploring whether knowledge can preserve:
Provenance
Authority
Evidence
Temporal validity
while making it available to AI systems.
Long-Running AI Workflows
Autonomous systems may need to remember why they made a decision.
They may need to revisit previous conclusions.
They may need to invalidate conclusions when new information appears.
This requires more than storing messages.
It requires lineage.
Explainable AI Systems
When an AI system produces a conclusion, users increasingly ask:
Why?
Knowledge lineage could potentially help answer:
What information contributed to this?
Where did it come from?
Was it verified?
What other knowledge did the system rely on?
This is an important direction for AI infrastructure.
The important question is not replacement
The wrong question is:
Can AIKOQL replace PostgreSQL?
Or:
Can AIKOQL replace ClickHouse?
Or:
Can AIKOQL replace a vector database?
Those comparisons may be useful when testing specific workloads, but they are not the central question.
The better question is:
What becomes possible when knowledge itself has a first-class lifecycle?
Can an AI system reason more reliably?
Can it distinguish historical information from current knowledge?
Can it trace derived conclusions?
Can it identify contradictions?
Can it reuse validated experience?
Can it explain why it retrieved something?
Those are the questions I am building AIKOQL to explore.
Where does AIKOQL fit?
My current answer is simple:
AIKOQL is not trying to replace rows, documents, vectors, or graphs.
Each of those abstractions solves a real problem.
AIKOQL is exploring what happens when we add another layer:
Knowledge with context, provenance, state, time, relationships, and lineage.
Rows store structured facts.
Documents store flexible information.
Vectors help discover semantic similarity.
Graphs represent relationships.
Knowledge Objects explore how information can become operational knowledge for AI systems.
That distinction is still being tested.
And I expect my understanding of it to evolve as AIKOQL evolves.
But this is the space I believe is worth exploring.
What comes next
In the next post, I want to move from the abstraction itself to one of the hardest practical problems:
From Documents to Knowledge Objects: Rethinking AI Data Ingestion
Because if Knowledge Objects are going to be useful, we need to answer:
Where do they come from?
Documents are not just text.
They contain:
Tables
Diagrams
Charts
Images
Formulas
Structured sections
Relationships
Flattening everything into plain text can destroy meaning.
So the next part of the AIKOQL journey will explore how information moves from raw data and multimodal documents toward structured knowledge.
The real challenge is not just storing knowledge.
It is understanding how to create it without losing the context that made the information meaningful in the first place.
AIKOQL is an evolving open project. The architecture and ideas described here are being actively tested and may change as the system encounters real workloads, benchmarks, and engineering constraints.
If you work with databases, vector search, graphs, RAG, AI agents, or knowledge systems, I would love your perspective.
Do you think AI systems need a knowledge-aware layer, or should these capabilities remain in the application layer built on top of existing databases?
