ModelDB is two separate products that share an idea, not code. One lives inside a mobile or wearable app and keeps its data sealed on the device. The other is a server you run: it stores AI models, documents and tables, and you work with them in plain sentences. Pick one, or use both.
Five functions linked into your binary. Every value and every key name is sealed before it touches disk, then written as DNA-style A/C/G/T text. No server, no network.
Store AI models, images, documents and database tables together; import, export, archive and ask in plain sentences, in a browser app or over a token-gated REST API.
They solve different problems and don't share code. mdc-lite is a library you link into an app; MDC Platform is a server you run. Both seal what they store.
| mdc-lite | MDC Platform | |
|---|---|---|
| What it is | An embeddable library, linked into your app's binary | A server you run and talk to |
| Where it runs | Inside the app itself — no network, no server | On a machine with Python, reachable over the network |
| What it stores | Small generic objects — settings, credentials, cached blobs. No AI models. | AI models, images, documents, database tables |
| CLI / desktop app | None — mobile/wearable embedding only | Yes — conversational CLI, browser Storage Explorer, REST API |
| How you talk to it | 5 functions: put / get / exists / delete / list_keys | Plain sentences — no SQL, nothing to train support staff on |
| Encryption | Mandatory — every value and every key name | Mandatory on the DNA archive tier and on agent-state streams (AES-256-GCM) |
| DNA-inspired encoding | Yes — every entry is stored as an encrypted ACGT sequence | Yes — the archive tier, same encrypt-then-encode model |
| External API access | N/A — no network surface | Bearer-token REST API with four roles (viewer to admin), for custom apps and NLU integrations |
| Data tools | None — a key-value store | Import and export (CSV, SQL, Excel, ER diagram), schema from a prompt, event-sourced agent state, confirmed deletes |
| Written in | Rust (C header for Swift, Kotlin and others) | Python (FastAPI, DuckDB) |
| Choose it when | Your app needs private on-device storage and no server is involved | Several people or services need to store, ask about and share data behind an API |
| Documentation | mdc-lite docs → | MDC Platform docs → |
A key-value store built for the places a server can't reach: a watch face, a phone app, a background service. Every value and every key name is sealed under XChaCha20-Poly1305 before it ever touches disk. No runtime, nothing readable outside the app that wrote it.
On this page: What it does Builds Quickstart
In the docs: Installation API reference On-disk format Security model What this isn't
Key names are hashed with a keyed BLAKE3 hash before they ever become a filename — a directory listing of the raw store reveals nothing, not even how your data is organized.
This library takes a 32-byte key and never generates, stores, or touches it beyond that. Real custody belongs to the platform's own secure hardware — iOS Secure Enclave / Keychain, Android Keystore / StrongBox — which is exactly where it should live.
Built in Rust with opt-level = "z", LTO, and symbols stripped. No garbage collector, no interpreter, no background thread — a handful of file reads and writes, nothing more.
get() on a specific key fails loud if it's been tampered with. list_keys() quietly skips anything it can't decrypt, so one bad or foreign file never hides every other valid key in the store.
Every operation is exposed through a five-function C header — bind it from Swift, Kotlin, or anything else that speaks C calling conventions. No wrapper generation, no FFI framework.
Every encrypted entry is DNA-encoded (2 bits per base — 00→A 01→C 10→G 11→T) before it's written, the same encoding MDC Platform's archive tier uses. It's ciphertext under the base letters, never plaintext — the mapping is public, encryption is what actually protects it.
| Platform | Artifact | Size | Status | |
|---|---|---|---|---|
| macOSApple Silicon | libmdc_lite.dylib | 348 KB | tests passing | Download → |
| Windowsx86_64, mingw-w64 ABI | mdc_lite.dll | 992 KB | compiled, unrun | Download → |
| Androidarm64-v8a — real devices | libmdc_lite.so | 376 KB | linked, unrun | Download → |
| Androidarmeabi-v7a — older devices | libmdc_lite.so | 252 KB | linked, unrun | Download → |
| Androidx86_64 — emulator | libmdc_lite.so | 484 KB | linked, unrun | Download → |
| iOS / watchOSrequires full Xcode to build | — | — | build from source | Instructions → |
| Wear OS | — (uses Android .so) | — | same as Android | Instructions → |
Sourceany platform, cargo build |
mdc-lite-v1.2.0-source.tar.gz | 19 KB | build it yourself | Download → |
Every build above ships from a single tagged GitHub Release (checksums included) - not loose files browsed out of the repo tree. "Compiled, unrun" means the build succeeds and produces a correctly formatted binary, but couldn't be executed in the environment that built it — there was no Wine, Android emulator, or physical device on hand to run it against. Not a hedge: the full verification story, artifact by artifact, is in BUILD_INFO.md.
use mdc_lite::LiteStore; let key: [u8; 32] = /* from platform secure storage */; let store = LiteStore::open("/path/to/store", key)?; store.put("diary/2026-08-24", b"...")?; let value = store.get("diary/2026-08-24")?; store.exists("diary/2026-08-24"); // bool store.delete("diary/2026-08-24")?; let all_keys = store.list_keys()?; // Vec<String>
#include "mdc_lite.h" MdcLiteStore *store = mdc_lite_open("/path/to/store", key); mdc_lite_put(store, "diary/2026-08-24", data, data_len); uint8_t *out; size_t out_len; mdc_lite_get(store, "diary/2026-08-24", &out, &out_len); // ... use out[0..out_len) ... mdc_lite_free_buffer(out, out_len); mdc_lite_close(store);
// via the C header, bridged into Swift let store = mdc_lite_open("/path/to/store", keyPtr) mdc_lite_put(store, "diary/2026-08-24", valuePtr, valueLen) var outPtr: UnsafeMutablePointer<UInt8>? var outLen = 0 mdc_lite_get(store, "diary/2026-08-24", &outPtr, &outLen) // ... Data(bytes: outPtr!, count: outLen) ... mdc_lite_free_buffer(outPtr, outLen) mdc_lite_close(store)
The server side of the project. Store AI models, images, documents and database tables together and work with them in plain sentences. No sentence ever becomes SQL: an LLM may propose what you mean, but a deterministic validator decides what reaches storage.
On this page: What it does Run it
In the docs: Installation Core concepts Agent state streams Encryption keys REST API Deployment
Create, read, update, delete and analyse by asking. Ambiguous words are clarified, deletes are confirmed, and no sentence ever becomes SQL — a deterministic validator, not the language model, decides what reaches storage. Read more →
AI models, images, documents, logs, tensors and tables are recognised from their content (not the filename) and tiered HOT / WARM / COLD / ARCHIVE. Read more →
A .safetensors file is parsed and every tensor stored and tiered on its own, so you can fetch a single layer without reading the rest. Read more →
The ARCHIVE tier seals data with AES-256-GCM, then writes it as base letters, with error correction and a corruption simulator. A software simulation — no physical DNA. Read more →
Create as many databases as you like, add typed tables, insert and browse — and find across every database and document at once. Read more →
Attach a Markdown design document, CSV, SQL script, ER diagram or an MDC export. A SQL script is parsed, never run; nothing is written unless the whole file is valid, and nothing is overwritten. Read more →
CSV, SQL, Excel, a design document with an ER diagram, or an MDC export file another instance can import. Exports are plain files — the sealing protects data inside MDC, not what you download. Read more →
Say create database shop with customers(name, email), orders(total decimal) or paste an ER diagram. MDC shows the design and creates it only when you reply yes. Read more →
An AI agent's state kept as a base plus timestamped events instead of an overwritten value, then rebuilt exactly as it was at any moment (model weights stay in the object store). Every record, including its times, is sealed per stream; a tampered or missing event is detected. Read more →
Drop a database or table, delete a row or stream. MDC says what would be lost and waits — a database needs its name typed — and anything but a yes cancels. The default database is protected. Read more →
Browse by type, tier or database; preview, archive or delete objects; and chat — import with a paperclip, export with a download button. Read more →
A REST API for your own UI or NLU (RASA included): every route needs a token, and its role — viewer, editor, db_admin, admin — decides what it may do. Read more →
An optional second port serves CPU, memory and per-database statistics as Prometheus metrics, JSON and a live event stream, and can publish the same snapshots to Kafka for a dashboard or monitoring system. Read-only, off until you turn it on. Read more →
A Dockerfile and Railway config with a health check and a persistent volume; the deployed Explorer asks for the API token. Read more →
You need Python. This starts the browser app (Storage Explorer) and the REST API on your own machine; Installation has the rest, and Deployment covers Docker and Railway.
# get it git clone https://github.com/saji1970/ModelDB.git cd ModelDB/mdc python -m venv .venv && source .venv/bin/activate pip install -r requirements.txt # the browser app and REST API at http://127.0.0.1:8000 python -m mdc serve # or the conversational shell python -m mdc # an API token for your own app or NLU python -m mdc token issue my-integration --role editor
Then ask it things: create database shop with customers(name, email), list models, find widget under 20000, create stream agent-1 with mood=calm. Every chat command →
Embed it in an app.
Run it as a server.
Both products: the DNA-storage whitepaper (what the DNA-inspired encoding is and isn't), and the repository.
Quantum key distribution transmits photons between two fixed physical endpoints over dedicated hardware. It's a network-link technology — there's no version of it that runs inside an app on a phone or a watch.
Grover's algorithm only halves a symmetric key's effective strength — 256 bits stays enormous. Quantum computers threaten asymmetric crypto (RSA/ECC) instead, which neither product uses to protect data.
No — verified, not assumed. A qubit's superposition decoheres to a fixed, data-independent state in a handful of T2 lifetimes even with nobody reading it, confirmed by solving the Lindblad master equation in QuTiP against its exact analytic solution. There's no hardware today that holds a quantum state at rest the way a disk holds bits. Full derivation →