Straight answers to the questions people actually ask. Where a question deserves a full page, the answer links to it.
Is it production-ready?
No. OMGDB is an early project (v0.0). The durability and codec layers have been hardened — per-record CRCs, torn-tail crash recovery, a crash-truncation test matrix, cross-platform CI — but the write-capable engine still holds the dataset in memory, and several areas are honest subsets of their MongoDB equivalents. Read the limitations table before using it for anything you cannot afford to lose, and treat the per-area “what works / current limit” table there as the source of truth.
Isn’t a plain-text op-log slow?
Writing text is not the bottleneck — fsync is. Durable writes are fsync-bound, the same physical wall every embedded database hits, whatever its file format. Batched writes share one fsync per batch and exceed 100,000 documents per second in-process; import-jsonl loads 50,000 documents in about 2 seconds. Reads never parse the log at all: they are served from derived indexes and cache sidecars, every one of which can be deleted and rebuilt from the log. At raw scan scale, mature engines are still faster today — but the text log costs you far less than intuition suggests. See performance.
Why not SQLite, MongoDB, or a vector database?
- SQLite gives you tables and SQL; OMGDB gives you documents and a MongoDB-style API with the same zero-server, one-file-ish deployment — and its source of truth is a text log you can read, not a binary page file.
- MongoDB gives you the query language with a server attached; OMGDB gives you a compatible subset with no daemon, no port, and no replica set — a directory you can
cat, copy, and check into version control. - A vector database gives you embeddings at scale; OMGDB builds vector search into the same store as your documents — persisted embeddings, hybrid filters, cited context packs — with a deterministic offline baseline embedder rather than a neural model.
The longer version, including what each alternative does better, is in the comparison.
Can my coding agent really use it?
Yes — that is the design center. The MCP server (omgdb mcp) exposes the engine as tools with enforced capability scopes, so an untrusted agent can be handed a database it is structurally unable to mutate. describe prints a live manual of the store — collections, inferred schema, indexes, validation rules — so an agent learns the database by reading one page. And errors are structured for self-repair: a typo in a query operator or a missing collection comes back with a did-you-mean hint instead of a dead end. See working with agents.
What happens if the process crashes mid-write?
The log is append-only, so a crash can only tear the last record. On the next open, the torn fragment is preserved to oplog.torn.bak and the log is trimmed to its durable prefix — a post-crash write can never splice into a half-written record. Committed data is untouched, and a transaction without its commit marker is discarded on replay. Then omgdb verify proves the store is consistent: it re-checks every record and every derived cache against the log. See storage & op-log.
Can I edit the op-log by hand?
Structurally, yes — each line is a canonical-JSON record, and the format is designed to be read and understood directly. But every record carries a CRC, so an edited line that no longer matches its checksum is detected as corrupt rather than silently accepted. If you do damage the log, omgdb repair reports the intact prefix and, only with explicit confirmation, truncates to it (backing up the original first). Treat hand-editing as a recovery and inspection superpower, not a daily write path. See storage & op-log.
How big can a database get?
The write-capable engine replays the log into memory, so the logical dataset must fit in RAM. The CLI and MCP server use direct paths that avoid full replay, but they currently decode whole cache sidecars per process. A paged store is the main gap to production scale and sits near the top of the roadmap; the honest details are in the limitations table.
What’s the license?
Dual-licensed: MIT OR Apache-2.0, at your option — the standard Rust-ecosystem arrangement. Contributions are accepted under the same terms.
Where’s the roadmap?
At /roadmap/: what recently shipped, what comes next with the honest reason each item is not done yet, and the principles that decide the order. Dated release notes live in the changelog.
Is there a TypeScript or Python client?
Not yet. A TypeScript binding over the CLI/JSON surface is a tracked roadmap item; other language bindings would follow the same pattern but are not scheduled. Today the two surfaces are the omgdb CLI and the MCP server — which is exactly the pair a coding agent needs.