Agentic Storage Engine

.adb storage is a native graph database that unifies all modalities with fast retrieval.

Agentic Database is the storage engine behind Query Memory. It is designed for rows, documents, entities, facts, and links without forcing every record through a SQL-only or vector-only model.

PLANNER + FUSION

Query Layer

Exact, text, vector, temporal, graph

MEMORY + RANKING

Intelligence Layer

Entity views, facts, evidence assembly

.ADB STORAGE

Data Layer

SQL rows, PDFs, notes, JSON, links, time, indexes

Storage Design

.adb is not a SQL dump with vectors bolted on.

The storage model keeps structured and unstructured data in one native format. SQL-like rows stay typed, documents stay searchable, and relationships remain queryable without splitting the system across separate databases.

Stored natively

  • SQL rows
  • PDF chunks
  • JSON events
  • Notes
  • Graph links
  • Time series

Segments

Records are persisted into append-oriented segments so storage can scale without replaying one giant in-memory table.

Typed Records

Structured rows can remain numeric and lightweight. Text and embeddings stay optional instead of being forced onto every row.

Recovery

WAL and snapshots are used for crash recovery so startup does not depend on rebuilding everything from raw history each time.

Layer Purpose Why it matters
Record block Stores canonical records Keeps original fields and metadata intact
Exact index Field:value lookup Fast filtering for rows and entities
Text index Keyword and BM25-style retrieval Useful for documents and extracted text
Vector index Similarity search Only populated for records that need embeddings

Architecture

ADB works as a layered engine, and each layer should explain itself visually.

Hover each layer to highlight what that part of the engine does and how the data flows from SDK entrypoints down into the .adb storage core.

External interface

Python SDK and HTTP entrypoints ingest files, rows, and direct agent writes into a single canonical record model.

Query interpretation

The planner inspects entity IDs, filters, goals, trust, and time range to choose the retrieval path instead of blindly embedding everything.

Typed indexing

Exact maps, text indexes, vector indexes, adjacency graphs, and temporal trees are maintained as separate retrieval structures.

Persistent engine

Segments, WAL, snapshots, and metadata blocks back the .adb format so recovery is deterministic and storage stays native to the engine.

Materialized outputs

Result packages, summaries, evidence lists, and memory views are assembled from ranked records after the planner finishes candidate fusion.

User-facing surface

This is where insert, query, update, delete, ingestion scripts, and future npm wrappers connect into ADB.

Execution routing

Exact filters go to exact indexes, text goals trigger lexical search, and semantic goals add vector retrieval only when embeddings exist.

Why it matters

Rows with mostly numeric values can still be retrieved accurately through exact, graph, and time indexes without forcing vector embeddings.

Rust path

The execution path for persistence and retrieval stays in Rust while higher-level ingestion and model integrations remain outside the hot path.

Final response

The agent receives structured output rather than raw rows, making ADB usable as a direct memory and retrieval layer.

Retrieval

Mix structured rows, notes, and exact entity queries in one API.

These examples show how to insert typed data, add unstructured notes, then query by entity or by condition without changing databases.

Insert

from adb import ADB

db = ADB("healthcare_demo.adb")

db.insert(
    data={
        "patient_id": "P1001",
        "age": 58,
        "state": "Texas",
        "condition": "prediabetes"
    },
    entity_id="patient:P1001",
    record_type="patient_profile"
)

db.insert(
    data={"text": "Patient shows elevated glucose and fatigue."},
    entity_id="patient:P1001",
    record_type="doctor_note",
    modality="text"
)

Query

patient_view = db.query(
    entity_id="patient:P1001",
    goal="current concern",
    top_k=5
)

condition_view = db.query(
    filters={"condition": "prediabetes"},
    goal="find related patients and notes",
    top_k=10
)

print(patient_view["records_found"])
print(condition_view["strategy_used"])

This is the core behavior: one typed insert path, one query path, and the planner chooses exact, text, vector, graph, and time retrieval under the hood.

Comparison

More than just document retrieval

Compare flat retrieval systems with an engine that treats structured data, documents, entities, and memory as first-class inputs.

Traditional Retrieval Agentic Database
Document retrieval only Retrieval across SQL rows, documents, graph links, and time
Manual ranking logic in app code Planner + RRF fusion inside the engine
Flattened documents for search Typed records plus optional text and vector indexing
Separate stores for text, vector, and metadata Single .adb format with native multi-index storage
Weak entity context Entity-centric memory, evidence, and relationship traversal
Operational glue between systems One insert path, one query path, one storage engine

Ready to build on .adb?

Start with one file, ingest mixed data, and query it through the same agent-facing API surface.