MiniJinja

A template loop, collapsed into a SQL projection

The usual shape is: pull rows out of DuckDB, loop over them in Python or Node feeding each into a Jinja render(), then push the results back. That's an extra hop and a serializer round-trip per template. This extension turns the whole loop into a single SQL projection — the template stays declarative, the data stays in the query, and rendering happens inline in DuckDB's vectorized executor. Anywhere SQL hands you a string column, MiniJinja can render it: per-recipient email bodies, one config file per row of a configuration table, dynamic SQL driven from a metadata table, or webhook/Slack JSON payloads built straight from the query that produced the event.

How it works

A single scalar function backed by the minijinja Rust crate. The first argument is the template (a VARCHAR literal or column); the second, when present, is any DuckDB JSON value — a literal, json_object(...), or a JSON column. There is no ATTACH, no secrets, and no template registry: just one function name and a couple of optional named arguments like autoescape.

• • Compiled per call, against the row's context: Each invocation compiles the template, binds the JSON context, and returns the rendered text. Because compilation happens per call, a template column is rendered row by row with each row's own context — there's no precompiled-template handle to manage and nothing persists between rows.
• • Strict Jinja2 semantics: MiniJinja deliberately tracks Python-Jinja2 behavior — undefined-variable handling, filter naming, scoping, autoescape rules. A template that renders correctly under Python's Jinja2 for these features should render the same here.
• • Trusted templates, not parameter-safe: Jinja interpolation is string substitution, not SQL parameter binding — it is not injection-safe. When you template SQL (the dynamic-SQL pattern), the template body and the values flowing through {{ ... }} must come from a source you trust. For untrusted input, render the SQL shape with MiniJinja and bind the values through prepared-statement parameters.
• • Autoescape on by default: HTML special characters in context values are escaped (B&O becomes B&O) — the safe default for HTML and email. Pass autoescape := false when generating raw text such as configs, SQL, or JSON payloads.

MiniJinja vs Tera

This catalog ships two Jinja-style template engines as DuckDB extensions: MiniJinja and tera. They overlap heavily — both render {{ var }} / {% for %} / {% if %} against JSON context, and for everyday substitution both produce identical output. The differences are real but narrow.

• • Pick MiniJinja for Jinja2 fidelity: MiniJinja deliberately tracks Python Jinja2 semantics — naming, scoping, filter behavior. Choose it when you have an existing Python-Jinja codebase you want your DuckDB templates to match, or when you're already fluent in Jinja2.
• • Pick Tera for the larger feature surface: tera ships a wider built-in filter and tester library, template inheritance via a template_path glob, and Tera-specific extensions to the Jinja syntax. Choose it when your templates lean on those features or when you already maintain a Tera template library.

Variable substitution

SELECT minijinja_render('Hello {{ name }}!', '{"name":"World"}');

Loops

SELECT minijinja_render(
  'Items: {% for x in xs %}{{ x }}{% if not loop.last %}, {% endif %}{% endfor %}',
  '{"xs":["A","B","C"]}'
);

Disable HTML autoescaping for raw text output

SELECT minijinja_render('{{ v }}', '{"v":"B&O"}', autoescape := false);