# Databricks Lakebase Insights: per-project setup and what stopped > Lakebase Insights now runs per project, on a schedule or on demand. Old observability schedules stopped, so what we would turn on and who should see it. By Andrey Taran, 23 October 2026. Databricks Field Guide, TechFabric. Canonical: https://databricks.techfabric.com/notes/lakebase-insights-moves-to-per-project-settings-with/ 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](https://docs.databricks.com/aws/en/release-notes/lakebase#lakebase-insights-moves-to-per-project-settings-with-on-demand-runs-beta), 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](https://docs.databricks.com/aws/en/oltp/projects/observability-ai-insights)). 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](https://docs.databricks.com/aws/en/release-notes/lakebase#lakebase-insights-moves-to-per-project-settings-with-on-demand-runs-beta). ```mermaid Where Lakebase telemetry and findings go after 19 October 2026 flowchart LR A["Lakebase project compute"] --> B["system.lakebase tables, kept 7 days"] B --> C["Insights run, scheduled or Run now"] C --> D["Findings on the Monitoring page"] D --> E["Fix with Genie, each step approved"] B --> F["Our own Delta copy for history"] G["Old observability configuration"] -.-> H["Stopped, dashboards frozen"] class C accent ``` ## 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](https://docs.databricks.com/aws/en/oltp/projects/observability-telemetry-reference)). A user who can read `system.lakebase` sees telemetry for every project in the account, and statement text shows as `` 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](https://docs.databricks.com/aws/en/oltp/projects/lakebase-genie)). 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](https://databricks.techfabric.com/guide/lakebase/) covers the project model this rests on, and the [Snowflake comparison](https://databricks.techfabric.com/guide/snowflake/) 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](https://docs.databricks.com/aws/en/oltp/projects/observability-ai-insights) 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](https://docs.databricks.com/aws/en/oltp/projects/observability-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](https://databricks.techfabric.com/guide/mlflow/) asks of a served model in production, where running something comes with a bill and a record to keep. > **Our position**: Re-enable Insights this week on every project an old observability configuration covered, schedule it daily only where production depends on the database, and give teams project-level CAN MANAGE for findings while keeping `system.lakebase` to a platform group.