SDKs & Drivers Overview

OmniData’s container format is a directory bundle containing SQLite databases and content-addressed blob storage. The databases are standard SQLite, which means any language with a SQLite library can read, write, and search them. No special SDK is strictly required.

That said, drivers and SDKs provide convenience: connection setup for both index.db and memory.db, PRAGMA configuration, embedding helpers, RRF search, blob management, and pipeline promotion. Here is the current and planned driver landscape.

The bundle is the API

This is the most important concept. A .omnidata container is a directory containing:

• index.db — resources, chunks, embeddings, FTS5, deltas, queue, kv
• memory.db — collections, edges, tags, memory records
• blobs/ — content-addressed files on the filesystem
• manifest.json — container identity and metadata
• adapters.json — adapter registry and state

You can open either database with:

• sqlite3 CLI
• Python’s built-in sqlite3 module
• Any SQLite binding in any language

You can read manifest.json and adapters.json with any JSON parser, and access blobs as plain files. If you can run SQL against SQLite and read files, you can work with OmniData. The drivers listed below are conveniences, not requirements.

Python (reference implementation)

The Python driver is the reference implementation. It provides:

• Connection management for both index.db and memory.db with correct PRAGMAs
• Async support via aiosqlite
• Adapter orchestration (discovery, scheduling, sync)
• Text chunking (sliding window, tree-sitter)
• Embedding generation (Nomic, OpenAI, local models)
• RRF search combining vector and FTS5
• Blob storage and retrieval via the blobs/ directory
• Pipeline promotion (bronze to silver to gold)

Install: pip install omnidata

Python is the recommended starting point for building adapters, running pipelines, and integrating OmniData into applications.

See the Python guide for usage examples.

Raw SQL

For read-only access, exploration, or integration into systems where adding a Python dependency is impractical, raw SQL works perfectly. Open the appropriate .db file, set the PRAGMAs, and query.

This is the right choice for:

• Shell scripts that need to extract data
• Languages without a dedicated OmniData driver
• One-off investigations and debugging
• Applications that only need to read, not write

See the Raw SQL guide for common queries and PRAGMA setup.

Rust (planned)

A Rust driver is planned for performance-critical use cases. It will expose a C ABI, making it callable from any language via FFI. Target use cases:

• High-throughput embedding pipelines
• Native macOS/Windows desktop applications
• CLI tools where Python startup time is unacceptable

The Rust driver will be a thin layer over rusqlite with the same PRAGMA and convention enforcement as the Python driver, managing both database connections within the bundle.

Swift (via C FFI)

Swift applications (macOS, iOS) can access OmniData databases through SQLite’s C API directly, or through the planned Rust driver’s C ABI. No dedicated Swift package is planned initially — the C FFI surface is small enough that a Swift wrapper is straightforward to write.

JavaScript / WASM

For browser-based and Node.js applications, OmniData databases can be accessed via:

• sql.js — SQLite compiled to WASM, runs in the browser
• better-sqlite3 — Synchronous SQLite for Node.js
• wa-sqlite — Another WASM option with VFS support

These are standard SQLite libraries. The only OmniData-specific setup is configuring the correct PRAGMAs and understanding which database (index.db or memory.db) contains the tables you need.

Choosing a driver