MLflow 3.17.0 Adds Per-Resource-Type Permissions and Opt-In Trace Rollups, and Requires a Coordinated Database Upgrade
MLflow 3.17.0, published October 7, adds sub-resource permission tiers and opt-in daily trace analytics rollups, and its notes require stopping all writers for SQL schema upgrades.
Overview
MLflow 3.17.0 was published on GitHub on October 7, 2026, according to the GitHub release page as read by The Machine Herald on October 10. The release notes say the version “includes several major features and improvements” and highlight five: finer-grained access control, opt-in analytics summaries for large trace datasets, evaluation-metric tracking against managed datasets, typed feedback for evaluation judges, and per-user scoping of saved assistant conversations. The release also carries a schema migration that the notes say applies to every SQL-backed server.
What Changed
Permissions. The release notes describe “Fine-Grained Permissions for Shared Resources” that “control access to contained resource types, including runs, traces, and versions, with wildcard grants and explicit DENY.” MLflow’s role-based access control documentation states that the sub-resource tiers are “available from MLflow 3.17; before that, access to a container implied access to everything inside it.” The same page lists tiers including run, trace, and logged_model inside an experiment, and registered_model_version inside a registered model. It also says tiers are wildcard-only: a grant such as (run, *, DENY) is valid, while a grant on a specific run ID is rejected with a 400 error. Per its permission-combination table, a DENY on a tier is not overridden by a MANAGE grant on the containing experiment.
Trace analytics. The notes describe “opt-in daily summaries and raw-query fallback” to reduce SQL analytics query overhead. According to the backend-store documentation, rollups “never change query results”: days not yet rolled up, and partial days at the edges of a requested range, are served from the raw path, so enabling them “only changes query speed.” The documentation says the feature requires a database backend and is not available for the file store. The MLFLOW_SQL_TRACE_ROLLUPS_ENABLED setting defaults to false, and the maintenance schedule defaults to 0 2 * * *, a five-field UTC cron expression. The documentation does not publish a speedup figure.
Evaluation and other items. The release notes list the ability to “associate aggregate logged-model evaluation metrics with the managed dataset that produced them” and to use built-in scorers and custom judges “with typed Boolean or categorical feedback.” Smaller items in the notes include mlflow.restore_experiment() and mlflow.restore_run() in the fluent API, OTLP ingestion metrics exposed for Prometheus, and an MLFLOW_ENABLE_AI_GATEWAY setting that lets administrators disable the AI Gateway.
Upgrade Requirements
The release notes state: “SQL-backed servers require a coordinated schema upgrade with all writers stopped and a restorable backup, even when daily rollups remain disabled.” They add that mlflow db upgrade <database-url> must run before restarting all replicas on the new version, and that “mixed-version rolling upgrades are not supported.”
The backend-store documentation lists the sequence: stop all MLflow servers and other writers, take or verify a restorable backup, run mlflow db upgrade, then start all replicas on the new version. It says that if the built-in Huey scheduling is used, periodic rollup tasks should be enabled on one replica only, and that multi-replica deployments should use the remote rollup job instead. It also says MLFLOW_SQL_TRACE_ROLLUPS_ENABLED is not a hot-disable switch once rollups have been populated.
What We Don’t Know
None of the three sources reports how long the schema migration takes or how much downtime to expect on large trace tables. No benchmark of the rollup speedup appears in the release notes or documentation.