Triggers fire for the writers you forgot about

A MongrelDB trigger is a cataloged engine structure, not a client-side callback, and it is row-level across INSERT, UPDATE, and DELETE, with BEFORE and AFTER on ordinary tables and INSTEAD OF on session views, which covers the three places people actually use triggers: audit rows, lightweight denormalization, and validation that has no business being reimplemented in every client. The SQL surface looks the way you would expect if you have written a trigger in anything since the nineties:

CREATE TRIGGER audit_order
AFTER UPDATE OF status ON orders
WHEN OLD.status <> NEW.status
BEGIN
  INSERT INTO order_audit(order_id, status)
  VALUES (NEW.id, NEW.status);
END;

The part worth reading twice is the commit behavior, because trigger expansion happens inside commit_transaction, which means the original write and every write the trigger produces land in one WAL transaction, and the unique, foreign-key, CHECK, and row-policy validation runs against the final expanded write set rather than against your write alone. A trigger that fails leaves no partial durable state behind, and that atomicity extends to the RAISE family in trigger bodies, where FAIL and ROLLBACK do not retain the SQLite-style partial row effects that have surprised a generation of developers, while RAISE(IGNORE) suppresses the current row operation and the later triggers for that row without throwing away the trigger work already staged. Recursive triggers are off by default, the way they should be, and enabling them is an explicit per-session PRAGMA recursive_triggers = 1;, with cycle and maximum-depth violations returning errors that name the trigger stack instead of hanging your commit.

One spec, every client

Kit does not invent a trigger language of its own, it hands the engine a declarative JSON spec, and that choice is the whole point, because a trigger stored by the engine fires for writes that arrive through Kit, through raw SQL, through the daemon’s HTTP surface, or through any of the native clients, and you do not end up with the usual SDK-shaped hole where the TypeScript path enforces the invariant and everything else hopes for the best:

import { trigger, newColumn, textValue } from '@visorcraft/mongreldb-kit';

const usersAudit = trigger({
  name: 'users_ai',
  target: { kind: 'table', name: 'users' },
  timing: 'after',
  event: 'insert',
  program: {
    steps: [{
      kind: 'insert',
      table: 'audit',
      cells: [
        // the audit table is keyed on the user id it records
        { column_id: audit.id.id, value: newColumn(users.id.id) },
        { column_id: audit.user_id.id, value: newColumn(users.id.id) },
        { column_id: audit.note.id, value: textValue('created') },
      ],
    }],
  },
});

db.createTriggerSync(usersAudit);

The same spec round-trips through createOrReplaceTriggerSync, dropTriggerSync, and the remote client’s createTrigger / replaceTrigger / dropTrigger, Rust keeps the spec as JSON so it tracks the engine schema exactly, Python accepts a dict or a JSON string, and migrations carry triggers as ordinary createTrigger ops so a drift check notices when the live database lost one. When a trigger rejects a write, every language surfaces the same stable TRIGGER_VALIDATION error category, so the catch block you wrote for the TypeScript path is the same shape you write for the Python path, which is the kind of boring uniformity that only shows up when the error comes from one engine instead of three SDKs.

Virtual tables are modules, not plugins

The virtual table side answers a different version of the same trust question, because the history of this feature is SQLite’s CREATE VIRTUAL TABLE and its eponymous table-valued functions, a genuinely good idea that came with a genuinely bad habit of loading native code into your process from SQL, and MongrelDB keeps the idea while closing the loading door: SQL cannot load anything, modules are registered by the embedding application on the session or allowlisted by the daemon embedding, and an application that cataloged custom tables has to register its module implementations again when it reopens, which is a deliberate inconvenience that makes “where did this code come from” a question with a one-word answer. What SQL can do is ask for a module by name:

CREATE VIRTUAL TABLE numbers USING series(1, 100, 1);
SELECT value FROM numbers WHERE value >= 95;

The contract between the planner and the module is where the seam actually sits, and it is a narrower seam than you might expect: the planner hands the module the projections, filters, ordering, limits, and estimates it has, the module reports which filters it accepts and which it wants left behind, and the engine applies the residual filters and the exact limits itself, so a module that understands nothing about pushdown is slow rather than wrong. Correctness never depends on how clever the module author felt that day, only performance does, and that is the right side of the line for a database to stand on.

The built-in modules cover the ground a real application asks for without anyone writing a module at all: series for integer ranges, json_each and json_tree plus their JSONB twins for traversal, schema_tables and dbstat for live metadata, kv_store as a durable writable key/value table, fts_docs as a writable full-text table with ranking, snippets, and highlights, and rtree_rects for rectangle overlap queries. The writable ones are the interesting half, because module writes stage through ExternalTxn and commit through the same shared WAL as your base tables, an explicit SQL transaction may mix base-table writes and module writes, trigger programs can target a module that declares itself writable and transaction-safe, and the module state lives under _vtab/ where recovery restores it, backup copies it, and check() and gc() keep it honest, so a virtual table in MongrelDB is not a view over a foreign system that your transactions cannot reach, it is a participant in the same commit as everything else.

Kit’s helper layer stays deliberately thin over that machinery, generating the SQL rather than hiding it:

import { createVirtualTableSql, virtualTable } from '@visorcraft/mongreldb-kit';

const docsFts = virtualTable('docs_fts', 'fts_docs', [
  'content=docs',
  'tokenize=porter',
]);

await db.createVirtualTable(docsFts);

console.log(createVirtualTableSql(docsFts));
// CREATE VIRTUAL TABLE "docs_fts" USING "fts_docs"(content=docs, tokenize=porter)

Migrations carry createVirtualTable ops the same way they carry trigger ops, the Rust and Python runners execute them through their embedded SQL session, and introspection is just PRAGMA module_list; and PRAGMA trigger_list; when you need to know what is actually registered. The observant reader will have noticed the trigger example used createTriggerSync while this one awaits, and that difference is the API telling you the truth about itself rather than an inconsistency you should smooth over, because trigger registry changes in the embedded client are synchronous catalog operations while virtual table creation rides the SQL path, which is async in TypeScript and is the reason migrateSync refuses virtual table ops outright.

Where the seam actually sits

The honest tradeoff is the same one it has always been, just with better defaults. A trigger is the right home for an invariant that must survive every writer, and it is the wrong home for anything that needs a network call or a side effect outside the database, because a trigger that calls a webhook is a distributed system wearing a costume. A virtual table is the right shape for data you cannot afford to copy or that lives somewhere else by nature, and it is the wrong shape for your hot path, because no matter how much pushdown the module accepts, you are still one indirection away from the storage the engine controls directly, and the Postgres foreign-data-wrapper crowd learned that lesson with two-phase commit as the tuition. What changed since the SQLite era is not the idea, it is who holds the keys: the modules come from your application instead of from the SQL text, the writes share your WAL instead of someone else’s, and the planner keeps the residuals so the seam between a real table and a foreign one is a performance question, never a correctness one.