If your team turned on Lakebase Advanced Postgres Telemetry and built a dashboard on what its observability configuration wrote to Unity Catalog, that dashboard has stopped getting new rows, and the scheduled insights behind it have stopped running. Databricks moved Lakebase Insights to per-project settings on 19 October 2026, still in Beta. The preview formerly named Advanced Postgres Telemetry now reads telemetry from the system.lakebase system tables, and anyone with CAN MANAGE on a project configures it in that project's Settings, with no observability configuration involved. The old schedules weren't carried over, so nothing comes back until someone turns Insights on project by project.
Turning it back on, project by project #
Insights is a background agent that reviews one project's telemetry at a time and raises findings with a severity, an evidence table and recommendations, on the project's Monitoring page under the Insights tab (Insights documentation). Each run uses compute and model tokens, the default frequency is every 24 hours, and the analysis instructions can't be changed, so how often it runs and on which projects are the only levers on that cost. We'd keep the daily default on projects that serve a production application and set the others to "No schedule, trigger manually", then press Run now on the Monitoring page when a developer reports something slow. A project that exists for CI branches rarely needs a daily diagnosis, and its runs are the easiest line on the bill to cut.
The work we'd do this week is mapping each old observability configuration to the projects it covered and enabling Insights in each of those projects' Settings. Where the preview isn't on yet, a workspace admin enables Lakebase Insights from the Previews page, which also switches on Lakebase Observability in System Tables. Workspaces that used Insights before already have it, according to the release note.
Who gets to read the telemetry #
This is the part we'd think hardest about. The telemetry lands in tables such as active_session_history, plan_history, pg_stat_statements_counters, ddl_history and postgres_logs, governed by Unity Catalog at the schema level (telemetry reference). A user who can read system.lakebase sees telemetry for every project in the account, and statement text shows as <REDACTED> unless the reader is an account admin or in the databricks_pii_access group. Findings are scoped to the project instead. Configuring Insights and viewing what it found both take CAN MANAGE on that project, and Genie can investigate from an insight without the user holding access to the tables themselves (Genie for Lakebase).
So we'd give an application team CAN MANAGE on its own project, let it work from findings, and keep the schema grant to a small platform group. Granting system.lakebase to every team that owns a database hands each of them every other team's query plans and Postgres logs.
When a team does press Fix with Genie, Genie asks for approval of each step, the queries it runs included, and never applies a fix on its own, which is the behaviour we'd want before letting it near a production branch. The Lakebase chapter covers the project model this rests on, and the Snowflake comparison is where we'd weigh what a bad day in production costs on each managed Postgres.
Seven days of evidence #
Records in system.lakebase are kept for 7 days, with no separate charge for storing them in that window. A finding can also drop off the Insights tab when its condition isn't in the latest window, which the Insights documentation says doesn't mean it was fixed. For a database people depend on, a week is short for answering "when did this start", so we'd schedule a small job that appends pg_stat_statements_counters and database_gauges into a Delta table of our own, and set each finding to Resolved or Not an issue as we act on it.
The telemetry reference warns that table and column names might change before general availability, so we'd keep that job's select list explicit and expect to edit it. It's the same discipline the MLflow chapter asks of a served model in production, where running something comes with a bill and a record to keep.