mnemiq: open-source text-to-SQL with a permission and query-plan gate on a 14B model

On September 8 agenticfabriq open-sourced mnemiq, a text-to-SQL system that does three things I have been arguing for: it tunes itself to your specific database rather than shipping a generic schema prompt, it checks permissions and inspects the query plan before anything executes, and it runs on a 14B open model. The team reports testing 28 configurations and rating 25,000-plus answers to get there. It is the first open reference implementation I have seen of the permission-plus-plan gate I described in local SQL assistant guardrails, and it is worth studying even if you never deploy it.

What the gate does

Two checks sit between generated SQL and execution. The permission check asks whether this user, through this assistant, is allowed to touch the tables and columns the query references. The query-plan check inspects the plan, in practice the EXPLAIN output, and rejects plans that would do something expensive or unexpected: a full scan on a billion-row table, a cross join, a query that would take the database down for everyone else. Both checks happen before execution, on the plan and the identity, not on the model's intent. That is the correct place. Every guardrail that tries to detect a bad query from the natural-language request is fighting the model; a guardrail on the plan is fighting the database, which is a fair fight.

Why tuning to the database matters

Generic text-to-SQL fails on the same things every time: the column that means something different from its name, the join path that is not the obvious one, the enum encoded as integers. mnemiq's approach is to tune the system to a particular schema, which is why the 28 configurations and 25,000 rated answers matter: those are the evaluation rounds that found which prompt, retrieval and model combination works on their data. Your data is different, so the number to care about is not their accuracy but the fact that the tuning and eval loop is reproducible on yours.

A text-to-SQL guardrail belongs on the query plan and the caller's permissions, not on the model's intentions, because the plan is the only thing you can actually verify.

Running on a 14B open model means the whole thing fits on a developer laptop or a modest team server, keeps the schema and the queries inside the network, and costs nothing per query. The tuning does the work that model size would otherwise do; a well-tuned 14B on a specific schema beats a generic 70B.

Where it is thinner than my guardrails

Two gaps, both called out in the September 9 brief and both real, plus two I would add.

• Destructive statements: a permission and plan check governs what a query reads, but the rule I insist on is a hard allowlist of SELECT and nothing else, enforced at the connection level with a read-only role, not in the application. Verify that the gate refuses DELETE, UPDATE, DROP and TRUNCATE structurally rather than by pattern.
• Row-level security: table permissions are coarse. The user who may query the orders table may not see other regions' orders. That has to live in the database as RLS policies tied to an impersonated identity, and the assistant has to connect as that identity, not as a service account.
• Output validation: a plan check says nothing about whether the result answers the question. Pair it with output validation on result shape and row count.
• Audit: log the generated SQL, the plan, the decision and the identity for every query, whether it ran or not.

How to evaluate it

• Point it at a staging copy of a real schema with a read-only role and RLS enabled.
• Feed it the fifty questions your analysts actually ask, including the five that should be refused.
• Measure refusals and false refusals separately; a gate that blocks everything is not safe, it is unused.
• Swap the 14B for whatever you already serve through Ollama and check the accuracy delta.

The honest limitation

I have not run mnemiq against a production schema; what I know comes from the release and the team's own write-up, and the 25,000 rated answers are their eval on their data. The architecture is right. Whether the implementation holds on your schema, with your permission model, is the test nobody can run for you.