43 posts filed under engineering.
MongrelDB Kit exposes the engine's storage knobs as one-line calls per table: transaction spill thresholds, mutable-run spill, compaction zstd level, result cache budget, and the deferred-versus-eager index build policy.
A synchronous native database call that takes forty milliseconds stalls every request your Node process is serving, so MongrelDB Kit ships genuinely non-blocking async twins for the hot read and write paths, and this post covers which ones are real and which ones are not.
Installing a database driver in PHP used to mean phpize, a compiler, and a prayer; the MongrelDB PHP client is pure PHP installed with one Composer command, and this post explains why that is still a feature in 2026.
An embedded database has no daemon to scrape and no slow query log to tail, so MongrelDB Kit puts the storage engine's own per-table counters directly on the database handle.
A durable commit costs about a thousand times more than the write itself, so MongrelDB Kit ships WriteBuffer, an opt-in micro-batching surface that amortizes one fsync across a thousand rows.
The PHP runtime argument is real for your application code, but a database client that speaks plain HTTP to a daemon does not participate in it, and here is the code to prove it.
MongrelDB triggers are engine-side and fire for every client that writes, and its virtual tables are app-registered modules instead of loadable native code, so audit behavior and foreign data both live inside the same WAL transaction as the rest of your rows.
MongrelDB Kit exposes recursive CTEs, window functions, CREATE TABLE AS SELECT, materialized views, and multi-statement execution through the same sqlRows surface, with recursive CTEs evaluated by MongrelDB itself and materialized view refreshes that publish atomically or not at all.
A huge share of the web still runs on hosting plans where you cannot compile anything, and a database client that ships as plain Composer files is the difference between deploying there and telling the customer to move.
The mongreldb-php client validates every permission string against a strict allowlist before it builds a GRANT statement, because DDL fragments cannot be bound as parameters and the classic prepared-statement advice does not cover them.
MongrelDB allows one primary key column per table by design, so a composite natural key like (tenant_id, slug) is modeled as a multi-column unique constraint enforced atomically at commit, with an optional surrogate auto-increment key when you need a point-lookup handle.
MongrelDB ships full-text relevance as an ordinary SQL function that scores whole Arrow batches per call, composes with WHERE and ORDER BY and window functions, and asks for no index up front, with the honest tradeoff that global IDF lives in the fts_docs virtual table instead.
MongrelDB stored procedures are versioned, checksummed definitions installed over HTTP, and the pure PHP client exposes the whole lifecycle as five typed calls whose name-keyed argument arrays map directly onto the procedure's declared params.
MongrelDB Kit stamps every applied migration with a content-aware SHA-256 checksum over its recorded intent and re-verifies it on every run, so editing a historical migration after it shipped fails loudly at the next deploy instead of silently re-shaping production.
The MongrelDB PHP client mirrors the daemon's two auth modes with one constructor argument each, and anything more exotic, from per-request token vending to signing proxies, goes behind a one-method TransportInterface you control.
MongrelDB Kit's typed schema DSL and its raw SQL surface are two front doors to the same engine rather than one compiling into the other, and knowing which door to use, and how to mix both inside a single migration, is most of the skill.
MongrelDB Kit ships TypeScript, Rust, and Python SDKs over a single Rust core, and a shared JSON conformance suite proves all three produce identical results and identical error codes on top of one shared query compiler.
The MongrelDB PHP client substitutes malformed UTF-8 instead of rejecting the whole request, and reserves hard errors for values like INF, NAN, and recursive structures that genuinely have no JSON representation.
The MongrelDB PHP client treats schema as typed data instead of SQL strings, so the same call that creates a table can be paired with a catalog read that proves the server stored what you think it stored.
The MongrelDB PHP client's fluent query builder names the index family in each condition instead of generating SQL for a planner to second-guess, so the index choice you made at schema time is the one that executes.
The MongrelDB PHP client stages multi-row writes locally, commits them as one atomic HTTP batch, and dedupes retries with storage-layer idempotency keys, so a timed-out request is safe to replay without building an outbox.
The MongrelDB PHP client maps HTTP status codes to a small typed exception hierarchy, so a 401 is an AuthException, a 409 is a ConstraintException carrying the server's error code and the failing operation index, and your catch blocks read like the failure modes they handle.
The MongrelDB PHP client hides all of HTTP behind a one-method TransportInterface, ships cURL as the default with a stream fallback, and lets you inject a fake for tests or a PSR-18 bridge for Guzzle without touching application code.
The MongrelDB PHP client opts into PHP 8.5's persistent cURL share handles to carry DNS, TLS sessions, and the connection pool across FPM requests, and silently falls back to per-request pooling on 8.4.
A walk through the actual HTTP surface mongreldb-server exposes, from /sql and /txn to sessions, pagination cursors, and the /kit/* typed routes, and why plain HTTP was the right transport bet.
MongrelDB ships as one compiled binary per platform and one shared library per ABI, with cluster and cloud integrations excluded at compile time, and that shape is an economic decision as much as an engineering one.
MongrelDB evaluates unique, foreign-key, and CHECK constraints atomically at transaction commit instead of per statement, which changes what a batch import can promise and what it has to fear.
An end-to-end technical walkthrough of MongrelDB, from transaction validation, WAL durability, MVCC, and PAX columnar runs to DataFusion SQL and hybrid retrieval.
A JSON column in MongrelDB is a typed column that the engine validates at write time and queries from the inside, so the schema-versus-schemaless argument stops being a binary you have to pick a side of.
A column type is not documentation, it is a promise the storage engine can spend, and MongrelDB's type system covers fixed-width integers, decimal128 money, five flavors of time, sortable UUIDs, native JSON, and typed arrays so the engine can plan bytes instead of guessing at strings.
A pure embedded engine never has to think about other processes, but MongrelDB is also a server, so it takes an exclusive advisory lock at open, fails fast by default, waits politely when you ask it to, and pushes genuine multi-process access through the daemon instead of through the filesystem.
Most database auth lives in middleware, which means every code path that skips the middleware skips the auth. MongrelDB stores Argon2id-hashed users and roles in the catalog and can enforce permissions on every transaction at the storage layer itself.
MongrelDB reconstructs change events from its own WAL and streams committed records to follower copies, so an embedded database can participate in replication and change data capture without bolting on a separate toolchain.
MongrelDB binds idempotency keys into the commit log itself, so a retried write is safe across process crashes and restarts, not just across network drops.
MongrelDB separates accepted writes from fsync-backed durable commits, batches WAL work with group commit, and flushes log-structured columnar runs later.
PHP 8.4 is the floor of the pure PHP client, and PHP 8.5, released in November 2025, is where the language gives us enough to stop writing workarounds for cURL and readonly cloning.
MongrelDB runs in-process or behind mongreldb-server, keeping one storage and query engine while changing ownership, authentication, serialization, and resource boundaries.
SQLite SEE is the official paid reference for SQLite encryption. Here is MongrelDB's open-source AES-GCM design, key hierarchy, WAL coverage, and search tradeoff.
MongrelDB's PGM learned-range index uses an epsilon-bounded piecewise linear model to predict sorted-key positions, then verifies the bounded range exactly.
Install the MongrelDB PHP 8.4+ client with Composer and connect to mongreldb-server over HTTP without compiling a custom PHP extension.
How an embedded vector database keeps HNSW candidates, operational rows, SQL filters, sparse retrieval, and exact reranking inside one Rust engine.
MongrelDB uses a Burrows-Wheeler transform and wavelet-tree FM-index for exact substring candidates that combine with SQL, vectors, ranges, and equality filters.
MongrelDB supports 35 languages through nine embedded native bindings and 26 language-native HTTP clients, with one engine contract under both boundaries.
