ArchitectureA supervised JVM-class runtime — OLTP on seven engines, OLAP on three. AI-native, MCP-native, observable as plain SQL.Read the architecture
Está viendo la edición Perú. Está viendo la edición Colombia. You're viewing the Pakistan edition. Cambiar a la edición global →Cambiar a la edición global →Switch to the global edition →

Every statement carries a purpose and an owner, and the catalogue lists itself

Each statement in the monitoring catalogue is classified by what it is for, from a cursor's main query to an export, and names the user it ran for. The catalogue lists its own tables with keys, triggers and queue limits.

A list of running statements is only useful if it says why each one runs and for whom. This release tags both.

Purpose and owner

  • A purpose per statement Cursor main query, refresh, horizontal and vertical joins, cursor and reorder data modifications, export, metadata, work and script. Thirteen data-modification sites, three export sites and four catalogue sites were tagged.
  • An owner Statements, errors and history carry the authenticated user by default, so a slow query has a name beside it.
  • Quieter logs A statement managed by an activation found at connection return logs at debug rather than warning, and error queues use one configured size at every level.

The catalogue lists itself

  • A catalogue table names every monitoring table with its primary key, its delete trigger and its queue limit. Running tasks cover executor and virtual-thread pools with drill-down. Cached statements and the three blob tables join, with delete triggers that clean files.
  • A stuck-task signal The leak watchdog exposes a pending-eviction count; growth across sweeps is the signal.

The session and script tiers of September could say what a run was doing because, since April, every statement already said why.