v1.20.0

Full Changelog: v1.19.1...v1.20.0

v1.19.1

Full Changelog: v1.19.0...v1.19.1

v1.19.0

Full Changelog: v1.18.0...v1.19.0

v1.18.0

Full Changelog: v1.17.2...v1.18.0

v1.17.2

Full Changelog: v1.17.1...v1.17.2

v1.17.1 — the DuckDB extension loads into DuckDB 2.0

mentat 1.17.1: the DuckDB extension loads into DuckDB 2.0

Changed

• One DuckDB extension binary works with DuckDB v1.5.6 and 2.0. The
  extension now uses DuckDB's stable C API, with v1.5.6 as the minimum
  version. Up to 1.17.0 it was locked to exactly v1.5.6, and DuckDB 2.0
  refused to load it:

  The file was built specifically for DuckDB version 'v1.5.6' and can only
  be loaded with that version of DuckDB. (this version of DuckDB is 'v2.0.0')
  

  The DuckDB Community Extensions registry builds with DuckDB 2.0 now, so
  this is what lets INSTALL mentat FROM community work for 2.0 users. A
  DuckDB patch release also no longer needs a new mentat release.

  Tested on one binary: the smoke test under the v1.5.6 CLI and a 2.0 CLI
  built at the registry's DuckDB commit (d54cbbe3, which reports itself as
  v2.0.0), plus the SQLLogicTest suite and the concurrency test under the
  duckdb Python packages 1.5.6 and 2.0.0.dev2610192346. The DuckDB
  extension's code did not change.

Security

• Cargo.lock updates rustls-webpki to 0.103.16
  (RUSTSEC-2026-0382)
  and webpki-roots to 1.0.10
  (RUSTSEC-2026-0381).
  Both are used only by duckdb-rs's downloader at build time and are not in
  any shipped binary.

PostgreSQL, SQLite, library

No change. ALTER EXTENSION pg_mentat UPDATE is a no-op step from 1.17.0.
The asset mentat-duckdb-v1.5.6-linux_amd64.tar.gz keeps its name; v1.5.6
is the minimum DuckDB version now, not the only one.

v1.17.0 — trusted install, get-else/missing? everywhere, predicates on computed values

mentat 1.17.0: install without superuser, get-else and missing? everywhere, predicates on computed values

New

• pg_mentat installs without superuser
  (#331). The database
  owner, or any role with CREATE on the database, can now run
  CREATE EXTENSION pg_mentat:

  -- as postgres
  CREATE ROLE app LOGIN;
  CREATE DATABASE appdb OWNER app;
  -- as app
  CREATE EXTENSION pg_mentat;
  GRANT USAGE ON SCHEMA mentat TO reporting;              -- app can grant access onward
  GRANT SELECT ON ALL TABLES IN SCHEMA mentat TO reporting;

  The role that installs pg_mentat gets access to it and can grant access to
  others. No other role gets anything (no grants to PUBLIC). Turning on
  row-level security and mentat_tune_indexes(false) still need a superuser.
  To restore a dump of a non-superuser's database, run the restore as that
  role. Details:
  multi-tenancy.md.
  Before this release, a non-superuser couldn't install pg_mentat at all
  (permission denied for language c). Even after a superuser installed it,
  no other role could use it.

• get-else and missing? on the embedded SQLite store and the DuckDB
  extension (#335).
  These were "unknown function" errors before. They now behave as on
  PostgreSQL and in Datomic: any number of patterns, a predicate on the
  result, and an error on cardinality-many attributes.

• Predicates on computed values (pg_mentat,
  #334). You can now
  filter on a value computed earlier in the query:

  [:find ?v :where [?c :t/value ?v]
                   [(get-else $ ?c :t/rank 0) ?r] [(> ?r 1)]]
  [:find ?s :where [?e :q/n ?n] [?e :q/s ?s] [(* ?n 2) ?d] [(> ?d 4)]]

Fixed

• +, - and / parse in queries. [(+ ?a 1) ?b] used to be a parse
  error.
• pg_mentat create_store() no longer fails with
  syntax error at or near "CASE".

Upgrading (PostgreSQL)

Install the files for your PostgreSQL major (pg_mentat-pg15 …
pg_mentat-pg19), then run ALTER EXTENSION pg_mentat UPDATE;. The upgrade
changes no tables or data; it only adds the installing role's grants. We
tested it on Debian 12 with PostgreSQL 15–19, upgrading an existing 1.16.1
database in place.

Known issue

• You can't write to a store created by create_store(). Transactions
  fail with relation "mentat_<name>.current_instant" does not exist. This
  has been broken since 1.5.0. Until it's fixed, use stores keyed by
  store_id as described in multi-tenancy.md. Fixing it needs a design
  decision
  (#337).

Full details: CHANGELOG.

v1.16.1 — get-else fix; pg_mentat tarballs load on glibc 2.34+ again

mentat 1.16.1: get-else fix, and pg_mentat tarballs that load on older Linux again

Fixed

• get-else failed in any query with more than one :where pattern.
  Every call errored with:

  ERROR: invalid reference to FROM-clause entry for table "datoms0"
  

  For example, this query failed on 1.16.0 and now works:

  [:find ?v ?p :where [?c :t/kind :chat] [?c :t/value ?v]
                      [(get-else $ ?c :t/private false) ?p]]

  get-else used to compile to a LEFT JOIN placed after the other patterns.
  PostgreSQL attached it to the last one only, so the join could not see the
  pattern that bound the entity. It is now a correlated subquery, so it works
  with any number of patterns, in any order, and more than once per query.

• get-else with asOf / since returns the value at that point in
  time. Before, it could return a later or superseded value.

• The 1.16.0 pg_mentat tarballs did not load on Debian 12, Ubuntu 22.04,
  RHEL 9 or Amazon Linux 2023. CREATE EXTENSION failed with
  version `GLIBC_2.38' not found. They were built on a glibc 2.39 host.
  1.16.1 is built on Debian 12 and needs glibc 2.34, as 1.15.0 did. The
  release job now fails if a build needs more
  (#336).

Changed

• get-else on a cardinality-many attribute is now an error, as in
  Datomic. It used to return one row per value, and only in single-pattern
  queries. Use a data pattern for such attributes.

Upgrading (PostgreSQL)

1. Install the .so and SQL files for your PostgreSQL major
   (pg_mentat-pg15 … pg_mentat-pg19).
2. Run ALTER EXTENSION pg_mentat UPDATE;. There is no schema change.

We tested this on Debian 12 with PostgreSQL 15–19. An existing 1.15.0
database upgrades in place and then returns the correct results for the
reported queries.

Known issues

• A get-else (or arithmetic) result can't be used in a predicate yet; it
  fails with unbound-var
  (#334). This was already
  the case before 1.16.1.
• The embedded SQLite store and the DuckDB extension don't implement
  get-else / missing?
  (#335).
• A non-superuser can't CREATE EXTENSION pg_mentat
  (#331).

Full details: CHANGELOG.

v1.16.0 — PostgreSQL 19 support

Warning: the pg_mentat tarballs in this release need glibc 2.38+ and do not load on Debian 12, Ubuntu 22.04, RHEL 9 or Amazon Linux 2023 (#336). Use v1.16.1, which also fixes get-else in multi-pattern queries.

mentat 1.16.0: PostgreSQL 19 support

pg_mentat now builds and runs on PostgreSQL 19, tested on 19rc1. Until
now pg_mentat could not be built on PostgreSQL 19: the pgrx 0.17 it was built
with has no PostgreSQL 19 bindings.

1.16.0 moves to pgrx 0.19.3, which supports PostgreSQL 13–19. pg_mentat needed
no code changes. The full test suite (1934 tests with scripting) passes on
PostgreSQL 13, 14, 15, 16, 17, 18 and 19rc1.

New

• Release tarballs for PostgreSQL 18 and 19. The assets now include
  pg_mentat-pg15 … pg_mentat-pg19. The PG19 build uses PGDG's
  postgresql-19 (19~rc1) package.
• CI tests PostgreSQL 13–19.

Changed

• Building from source needs Rust 1.96 and cargo-pgrx 0.19.3:

  cargo install --locked cargo-pgrx --version 0.19.3
  cargo pgrx init --pg19 $(which pg_config)
  cargo pgrx install --release --no-default-features --features pg19

  The library crates on crates.io (mentatdb and friends) still build on
  Rust 1.88.

• duckdb 1.10506.1. This moves its build-time zip dependency to 9.x, which
  fixes RUSTSEC-2026-0367/0368/0369.

Upgrading

• PostgreSQL: ALTER EXTENSION pg_mentat UPDATE TO '1.16.0';. This is a
  no-op step with no schema change. Reinstall the .so for your PostgreSQL
  major first.
• Nix: pg_mentat-pg14 … pg_mentat-pg18 are unchanged. There is no
  pg_mentat-pg19 yet, because nixpkgs doesn't have a PostgreSQL 19 release
  build.

Known issue

A non-superuser still can't CREATE EXTENSION pg_mentat. It fails with
permission denied for language c. This is
#331, reopened. The 1.13.0
"trusted install" change never worked, and 1.15.0 fails the same way. Install
as a superuser for now. The fix changes who can access the mentat schema, so
it will get its own release.

Full details: CHANGELOG.

v1.15.0 — transaction functions everywhere; DuckDB correctness fix + connection pool

mentat 1.15.0: transaction functions everywhere, a DuckDB correctness fix, and a DuckDB connection pool

DuckDB users: upgrade

In 1.11.0–1.14.0 the DuckDB extension could silently return no rows. This
happened once a mentat database had been opened by a plain duckdb CLI (or any
client without the extension) after a mentat session. From then on, every
[?e :attr _] query came back empty, and retractions failed with
FATAL ... Failed to delete all rows from index.

The cause is a DuckDB 1.4.0–1.5.6 bug,
duckdb/duckdb#26828: the
first checkpoint after a WAL replay loses rows from secondary indexes. The
upstream fix (#26814) isn't released yet.

1.15.0 stores have no secondary indexes. DuckDB 1.5.6 never used them, and
inserts are 8.5x faster without them. Opening an existing store with 1.15.0
drops the old indexes, which also repairs a store that was already hit. We
verified this on a store that the 1.14.0 extension had corrupted.

New

• Transaction functions on the embedded SQLite store and the DuckDB
  extension (mozilla#333). The :db/fn functions that 1.14.0 added to PostgreSQL
  now run on every backend that has the scripting interpreter, with the same
  semantics:

  • the embedded store with the mino feature, the SQLite extension and the
    CLI;
  • the DuckDB extension.

  [{:db/ident :person/birthday
    :db/fn "(fn [db who]
              (let [a (ffirst (mentat.store/q db '[:find ?a :in $ ?n
                                                   :where [?e :person/name ?n] [?e :person/age ?a]] who))]
                [[:db/cas [:person/name who] :person/age a (inc a)]]))"}]
  [[:person/birthday "Alice"]]

  The function sees the database as of the start of the transaction and runs
  in the edn_eval sandbox. Its tx-data is spliced into the same transaction.
  MENTAT_TXFN_MAX_DEPTH (default 16) bounds recursion; on PostgreSQL it is
  mentat.txfn_max_depth. Existing stores need no migration.

Faster (DuckDB)

• Concurrent mentat calls now run in parallel. The extension opens a pool
  of connections when it is loaded (MENTAT_DUCKDB_POOL, default one per core,
  at most 8). Writes to one store still take turns; reads, and writes to
  different stores, run concurrently.

  • Point lookups at 8 client threads: ~320 → ~1500 ops/s.
  • Writes from 8 threads, one store each: 65 → 291 tx/s.
  • Single-client latency is unchanged.

  Benchmarks: benchmarks/results/duckdb-perf-2026-10-15T010700Z/findings.md.

Other

• The Quack listen backlog (5) is reported upstream as
  duckdb/duckdb-quack#318.
• sparsemap was evaluated and not adopted
  (docs/design/sparsemap-evaluation.md).

Upgrading

• PostgreSQL: ALTER EXTENSION pg_mentat UPDATE TO '1.15.0'; is a no-op
  edge, with no schema change.
• Embedded / crates.io: mentatdb = "1.15.0".
• DuckDB: FORCE INSTALL mentat FROM community; LOAD mentat; once the
  registry update merges. Until then, use the mentat-duckdb-v1.5.6-linux_amd64
  asset attached to this release, loaded with -unsigned.

Full details: CHANGELOG.