Mastra's 1.65 rewrites how agents query trace history

Mastra's core package moved to 1.65.0 with a trace-query contract that works the same way whether the traces sit in ClickHouse, DuckDB, or Postgres. Bounded time ranges, recursive predicates on traces, spans and scores, thread grouping, and cursor pagination all get validated and rejected before any storage adapter runs, per the release notes.

That matters for anyone running agents that log to more than one backend. Before this, a team switching from Postgres to ClickHouse for trace storage had to rewrite its query layer. Now the validation and query shape stay fixed while the adapter underneath changes.

The release also adds tenant-scoped trace deletion, capped at 1,000 trace IDs per request, that cascades to spans, scores, feedback, metrics and logs in one call. That's a real gap closed. Deleting a trace used to mean chasing its child records across five tables by hand or writing your own cascade.

The breaking part sits in a different package. @mastra/factory loses its global rules object entirely, and defineBoard() now requires a kind and a role on every phase. Anyone who built board configs against the old shape needs to add those fields before upgrading, and there's no compatibility layer mentioned in the release to bridge the gap.

The two changes ship in the same version number but serve different audiences. Teams evaluating storage backends get a cleaner story. Teams already using Factory boards get a chore. If you're on @mastra/factory, check your board definitions before bumping the version, not after.