Built-in user accounts mean you can gate access to your database from the same process that opens the file—no OAuth provider or HTTP middleware required for simple cases. Register with a username and password, log in to establish a session, log out when done, and query whether a user is currently authenticated. That is enough for single-user tools, shared kiosks, or prototypes where you only need basic identity, not federation.

db.registerUser("admin", "secure123");
db.login("admin", "secure123");
db.isAuthenticated("admin"); // true
db.logout("admin");

Each collection can have a schema object: field names map to types such as string and number, with required to reject documents missing fields and unique to enforce no duplicate values in that field (for example one account per email). Validation runs on insert and update, so bad data never silently lands in the file. You can evolve schemas as your app grows—tighten constraints when you are ready, or start without a schema and add one later where ports support it.

db.defineSchema("users", {
  name: { type: "string", required: true },
  email: { type: "string", required: true, unique: true },
  age: { type: "number" },
});

Filters use the same style of operator objects many developers know from MongoDB: comparisons ($gt, $gte, $lt, $lte), equality ($eq, $ne), membership ($in, $nin), and pattern matching ($regex). Nest operators to express ranges (e.g. age between 18 and 65) or combine conditions across fields. The same filter document applies to find, findOne, updateOne, and deleteOne, so you learn one pattern and reuse it everywhere.

db.find("users", { age: { $gte: 18, $lt: 65 } });
db.find("users", { email: { $in: ["a@b.com", "c@d.com"] } });

On-disk layout is designed to stay compact for typical document workloads, so your .mgdb file remains easy to copy, back up, or attach to a bug report. Because the format is shared across official ports, you can create data in Node, inspect it with the CLI, and process it in Python or Go without a separate export step—as long as you use compatible library versions.

Everything lives in one database file: all collections and metadata share that path. There is no background daemon—your process opens the file, acquires whatever locking the implementation provides, and persists changes. That makes backups a file copy, simplifies “reset this machine” stories, and runs in air-gapped or container environments where opening a TCP port to MongoDB or Postgres is not an option.

Create documents with insertOne. Read with find (filtered), findOne (first match), or findAll (optionally filtered). Update with updateOne using a filter plus new field values. Delete with deleteOne and a filter. The filter object uses the same operator vocabulary everywhere, which keeps mental load low when you move from querying to updating or removing rows.

db.insertOne("users", { name: "Alice", age: 30 });
db.findAll("users");
db.updateOne("users", { name: "Alice" }, { age: 31 });
db.deleteOne("users", { name: "Alice" });

The official shell talks to the same engine as the libraries. Point it at a .mgdb file (or a directory that resolves to one), then use dot commands for meta-tasks: help, exit, listing databases and collections, viewing schema, toggling auth context, and controlling how results print. Data commands accept JSON for documents and filters—insert, find, findOne, update, delete—so you can reproduce production queries during support or migrate small datasets without a custom script.

$ ./mgdb ./mydb

mingledb> .collections
users

mingledb> insert users {"name":"Alice","email":"alice@example.com","age":30}
Inserted 1 document.

mingledb> find users {"age":{"$gte":18}}
  { "name": "Alice", "email": "alice@example.com", "age": 30 }
(1 document(s))

MingleDB CLI on GitHub →