7 posts filed under sql.
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.
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'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 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.
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.
