Diagnose and fix issues with Genie

Important

This feature is in Beta. Workspace admins can control access to this feature from the Previews page. See Manage Azure Databricks previews.

In the Lakebase UI, Genie diagnoses and fixes your database. You ask about a specific problem in your own words, and it investigates using the same telemetry as Insights: live Postgres state, query plans, wait events, and DDL and schema-change history. This is the same Genie you use across the Lakehouse and Apps; here it works on your Lakebase project.

Genie works as a step-by-step conversation: it shows its reasoning and asks you to approve each action, including the queries it runs while investigating. Any fix, including a database change, needs your explicit confirmation before it's applied.

This page walks through a common production incident (a deploy that drops a column the application still queries) to show what asking Genie for help looks like end to end.

Prerequisites

The scenario

A schema change runs ALTER TABLE users DROP COLUMN bio as part of a routine deploy. The application still reads that column on its profile page. Within minutes, profile-page requests start failing with column "bio" does not exist, and the application's error rate climbs.

How a Genie investigation flows

What Genie finds and recommends depends on your data and the issue behind it, so treat this as illustrative, not a script you'll see verbatim. Open Genie from your project (it picks up your project, branch, and endpoint context automatically) and describe the symptom. From there, a typical investigation moves through four stages:

  1. You describe the symptom. Ask in plain language, the way you'd tell a colleague: "Why is the error rate up?" You don't need to know the cause, the failing query, or which table is involved.
  2. Genie correlates and reads history. It ties the error to the failing query, then checks DDL history for what changed. DDL history doesn't capture every change (one made just as a compute resumes from scale-to-zero can be missed), so when a record is missing, Genie says so and falls back to comparing the table's current columns against what the query expects. Either way, it identifies bio as the dropped column. This is the same history Insights reads, so Genie can pick up where a background insight left off.
  3. Genie proposes a recovery, grounded in what it found. Typically it starts with a point-in-time branch created just before the change: an instant, copy-on-write clone that shares storage with production, so it's cheap enough to spin up for any fix. From there, recovery is a conversation: Genie might copy the missing data back into your current table, or switch your application to the restored branch. Some paths need a detail from you along the way, such as a connection string Genie can't discover on its own.
  4. You confirm before anything is applied. Genie never restores, modifies, or applies a fix on its own. It reports the actions it takes, but verify consequential ones (a restore point, a deleted branch) in the Lakebase UI before you rely on them.

Limitations to be aware of

  • Some generic Genie UI elements (such as Customizations, Automations, Spaces, and Add context) currently appear in Genie but aren't functional yet.
  • A Genie conversation continued from outside the Lakebase UI (for example, from a notebook) keeps the conversation history but loses the original page's tools and context. Start new investigations from inside the Lakebase project for the most reliable results.
  • Branches and endpoints appear by internal ID, not a display name like "production." If Genie's answer is ambiguous about which branch or endpoint it means, cross-reference the ID in the Lakebase UI. For more, see the overview limitations.

Next steps

  • Last updated on