What is OmniData?

OmniData (.omnidata) is an open format for storing, searching, and transporting knowledge. It is a directory bundle — a folder that contains multiple specialized files but presents itself as a single unit to the user, the same way macOS .app, .key, and .band bundles do.

Inside the bundle:

manifest.json — identity and schema version
index.db — SQLite database for search indexes, resources, and metadata
memory.db — SQLite database for hierarchy, relationships, and graph traversals
blobs/ — content-addressed filesystem for binary content (PDFs, images, recordings)
adapters.json — registered adapter configurations
ingress.log — append-only log of what entered and when

The key insight: SQLite for what SQLite is good at (search, queries, transactions), filesystem for what the filesystem is good at (large files, streaming, OS-level compression, snapshots, deduplication).

What can OmniData enable?

AI agents can open a .omnidata bundle to access a person’s complete knowledge context without re-explanation. Two SQLite databases and a blob directory — no server, no API key.
Role-based isolation — a person wearing multiple professional hats can keep each role’s knowledge in its own .omnidata bundle, with no data leakage between them.
Portable knowledge — copy or zip a .omnidata directory and the recipient has everything: the content, the search indexes, the relationship graph, the metadata. No external dependencies.
Multi-modal capture — screenshots, voice recordings, PDFs, web pages, notes, emails, and messages all live in one container, searchable by meaning. Blobs live as real files on disk, not packed into database rows.

Why does OmniData matter?

Depending on where you sit in the ecosystem, OmniData serves different purposes.

AI application developers: OmniData provides a universal knowledge store that any AI application can read. Two embedded databases with documented schemas. Build once, access from CLI tools, browser extensions, desktop apps, and MCP servers.
Knowledge workers: OmniData captures your digital life — everything you see, read, write, and say — in a format that’s searchable and portable. Switch machines, switch tools, the knowledge travels with you. It’s just a folder — cp -r, rsync, AirDrop, zip it.
Agent builders: OmniData gives agents memory that persists across sessions, scoped to the right context, with semantic search and graph traversal built in. The separation of index.db and memory.db means search and relationship queries never compete for the same locks.

Design Principles

Directory bundle, single identity. Multiple internal files, but the OS treats it as one thing. Double-click it, move it, zip it — it behaves like a file.
SQLite for queries, filesystem for content. Metadata, indexes, and relationships live in SQLite. Binary content lives as files on disk, named by SHA-256 hash. Each tool does what it does best.
Filesystem-as-runtime. Because blobs are real files, you get btrfs compression/snapshots/dedup, ZFS send/receive, APFS clones, and S3-compatible backends for free. The OS and filesystem do the heavy lifting.
Two databases, separated by access pattern. index.db handles search (FTS5, embeddings, resource metadata). memory.db handles graph traversals (hierarchy, relationships, edges). Different workloads, different files, no lock contention.
Machine-first. Field names, URI schemes, and metadata are optimized for unambiguous machine parsing, not human brevity.
Adapter-fed. Content enters through adapters — modular plugins that discover, extract, and enqueue content. The format defines the storage contract; adapters define the ingress contract.
Soft deletes only. Nothing is ever hard-deleted. Every record has a deleted_at column.
Content-addressed blobs. Binary content is stored once by SHA-256 hash in fanout directories (blobs/ab/ab3f7c...). Multiple resources can reference the same blob without duplication.
Embeddings are portable. Vectors are stored as float32 BLOBs with the model name recorded. Any runtime can read them; any runtime can re-embed.