OMGDB overlaps with four kinds of tools: embedded SQL databases, document servers, vector stores, and the humble JSON file. This page compares deployment model, API, and readability — qualitatively and honestly, including the trade-offs where the alternative wins. No benchmark tables: the engines below are mature in ways a v0.0 project is not, and at raw scan scale, mature engines are still faster today. What OMGDB trades for that is a store an AI agent — or you, with cat — can read, verify, and safely mutate.
The recurring themes on OMGDB’s side of the ledger:
- A readable canonical log. The source of truth is append-only NDJSON you can
cat, diff, and audit; every binary artifact is derived and rebuildable. - Self-verification.
omgdb verifyre-proves at runtime that replaying the log reproduces the entire state, caches included. - Agent surfaces. A scoped MCP server,
explain/diagnose/suggest-indexes, did-you-mean errors, and the reversible plan → apply → rollback mutation loop. - One store. Documents, secondary indexes, vector embeddings, and imported Markdown live in a single op-log-backed store with one durability story.
And the recurring trade-offs, stated once so each section doesn’t repeat them: OMGDB is single-process (an exclusive advisory lock; no concurrent clients), the write-capable engine keeps its working set in RAM, and it is an early project without decades of hardening behind it.
vs SQLite (+ JSON1 / sqlite-vec)
Shared strengths. Both are embedded and serverless: one path on disk, no daemon, no port, no ops. Both are ACID with a single-writer model, and both travel as a file you can copy around (for OMGDB, via omgdb pack).
Where OMGDB differs. Documents are the native model, not a layer. With SQLite you reach JSON through the JSON1 functions inside SQL, bolt on sqlite-vec for embeddings, and FTS for text — each an extension with its own dialect. OMGDB speaks MongoDB-style filters, updates, and aggregation directly, and vectors and Markdown are built into the same store. The deeper difference is legibility: a SQLite file is an opaque binary page format that requires the library to read, while OMGDB’s source of truth is text — history included, since the log records every operation — and the database can prove its own integrity with verify.
Honest trade-offs. SQLite is among the most battle-tested software artifacts in existence: decades of tuning, exhaustive test suites, deployment on billions of devices. It reads faster at scan scale, supports many concurrent readers in WAL mode, offers a full SQL engine with joins and window functions, and handles databases far larger than RAM. If your data is relational, or your working set is huge, SQLite is the right default.
vs MongoDB
Shared strengths. The API. OMGDB implements a compatible subset of MongoDB’s document model, query and update operators, and aggregation pipeline — the same filters, the same $set/$push, largely the same stages. Knowledge transfers in both directions.
Where OMGDB differs. Deployment. MongoDB is a server: a process to run, a port to secure, authentication, replica sets, an ops surface. OMGDB deploys like a file — create a directory, point the CLI or the MCP server at it, done. That makes it fit where a MongoDB instance is overkill: local tools, per-project stores, test fixtures, an agent’s working memory. And unlike a MongoDB data directory, an OMGDB store is something you can open in a text editor and audit line by line.
Honest trade-offs. MongoDB is a distributed database; OMGDB is not and does not pretend to be. No replication, no sharding, no change streams, no concurrent network clients, and the operator set is a growing subset rather than the full surface. If multiple services need simultaneous access to the same data, or the dataset outgrows one machine’s memory, you want the server.
vs dedicated vector stores (Chroma / LanceDB-class)
Shared strengths. Persisted embeddings, k-nearest-neighbor search, and hybrid retrieval — vector similarity combined with structured metadata filters (vsearch --filter).
Where OMGDB differs. Vectors are not a separate database to keep in sync. Embeddings live in an op-log-backed sibling collection next to the documents they describe, with provenance: vsync refreshes them incrementally, vstale detects which are out of date and why, and context packs assemble token-budgeted, cited retrieval bundles straight from the store. One durability model, one verification story, one backup — instead of a document database plus a vector database plus glue code that drifts.
Honest trade-offs. OMGDB’s kNN is flat, exact cosine — there is no approximate-nearest-neighbor index (no HNSW), so a dedicated vector store scales to far larger embedding counts. The bundled embedder is a deterministic bag-of-words hashing baseline, useful offline and in tests but not a neural model; a real embedding model is a drop-in for the Embedder trait, but you bring it. For millions of vectors behind a production semantic-search feature, use a dedicated store.
vs plain JSON files
Shared strengths. Human-readable, git-diffable, zero infrastructure, no lock-in — the format outlives the tool.
Where OMGDB differs. A JSON file you rewrite in place is one crash away from truncation. OMGDB keeps the readability but adds the database: appends are CRC-framed and fsync-ordered, an interrupted write is recovered automatically, edits are history (append a new record) rather than destruction (rewrite the file), and multi-document changes commit atomically. On top of that sit real queries instead of load-parse-filter loops, secondary indexes, schema validation as an enforced write contract, and verify as a standing proof the store is intact.
Honest trade-offs. Few, but real: a store is a directory plus a tool dependency, where a JSON file is literally nothing. For a config file, a lockfile, or data that one program reads whole and rewrites rarely, a plain file remains the right amount of technology.
Choosing
Choose OMGDB when:
- You want an embedded, zero-server store with a MongoDB-style API.
- The data should be readable, auditable, and diffable — including its history.
- An agent will create, query, or mutate the store, and you want scoped tools, self-describing introspection, repairable errors, and reversible writes.
- Documents, vectors, and Markdown belong together in one store with one durability story.
- The working set fits in memory and one process at a time is acceptable.
Choose SQLite when: the data is relational, the dataset may exceed RAM, you need concurrent readers, or you need the most battle-tested embedded engine there is.
Choose MongoDB when: multiple services share the database over the network, you need replication or sharding, or you rely on parts of the API beyond OMGDB’s subset.
Choose a dedicated vector store when: embeddings number in the millions and ANN indexing is the point.
Choose plain JSON files when: it’s configuration, not data — one reader, rare writes, no queries.
Related
- Overview — what OMGDB is and the three invariants behind the design.
- Performance — what’s fast today and the current frontier, stated honestly.
- Quickstart — from an empty folder to an agent-ready store.
- Architecture — the op-log, the derived caches, and the crate map.