What you will be able to do
- Recognise when a scenario calls for Unity Catalog because the requirement is access control, lineage, auditing or governed AI assets
- Recognise when a scenario calls for Lakebase because the requirement is low-latency transactional reads, agent memory or online features
- Choose between short-term and long-term agent memory backed by Lakebase
- Pick the right bridge between the lakehouse and Lakebase: synced tables inbound, Change Data Feed outbound
Key concept
Unity Catalog as the governance substrate — Unity Catalog is not one tool among four peers: it is the governance layer underneath data and AI work on Databricks, and Lakebase, MCP servers and MLflow traces all plug into it. Pick the other three for what they do; Unity Catalog decides who may do it and records that it happened.
1.Unity Catalog: the layer the other tools sit on
Tool-selection questions describe a scenario and ask which part of the Databricks stack fits it. The four candidates are Unity Catalog, Lakebase, MCP and MLflow 3. They are not interchangeable, and they are not all at the same level. Unity Catalog is described as the unified governance layer for data and AI. When it is enabled, it works automatically under every data and AI interaction, "tracking lineage as data and AI assets are used, logging activity for auditing", and enforcing access control when someone queries a table or calls a model. You do not call it the way an agent calls a tool. It sits under whatever the agent calls.
Unity Catalog treats every governed asset as a securable object, meaning something you can grant permissions on to users, service principals or groups. That covers more than tables: views, volumes, functions, models and services (model services and MCP services) all use the same three-level namespace. Its built-in capabilities follow the same pattern. They include access control (privileges, attribute-based policies, row and column filters), discovery through Catalog Explorer, automatic lineage "from source data through to models, services, and dashboards", an audit log system table, data classification, data quality monitoring, data sharing, and AI governance. The guide sums up AI governance as a single job: "Govern AI assets and AI traffic using Unity Catalog and AI Gateway."
So the selection rule is: if the scenario's real requirement is who may access something, where it came from, or what happened to it, the answer is Unity Catalog, even when the asset is an agent tool or a model rather than a table.
Checkpoint 1 of 4· Check yourself
A compliance officer needs a complete record of which principals accessed a customer table and which downstream models were built from it. Which tool covers both needs?
Access records and source-to-model lineage are governance concerns. Unity Catalog tracks lineage and logs activity for auditing automatically. MLflow traces cover agent executions, not who accessed a table.
“tracking lineage as data and AI assets are used, logging activity for auditing”Source: docs.databricks.com
Sources1
2.Lakebase: where an agent keeps its state
Lakebase is "a fully managed Postgres database integrated into the Databricks platform". Choose it when the scenario needs a transactional, low-latency store that an application or agent reads and writes while it is running. Its documented roles include low-latency app backends, serving lakehouse data, and, for AI and ML, use "as an online feature store for ML models, or as a state store for agents."
The agent case matters most for context engineering. The documentation says it plainly: "Agents need persistent storage to maintain context across turns and sessions." Lakebase provides that storage as two kinds of memory, and "You can implement either or both memory types in the same agent."
| Memory type | What it does | Scenario cue |
|---|---|---|
| Short-term memory | Captures context within a single conversation session using thread IDs and checkpointing | Follow-up questions that depend on earlier turns |
| Long-term memory | Extracts and stores key insights across multiple conversations | Personalized responses based on past interactions; a user knowledge base that improves over time |
Lakebase-backed memory works on two deployment targets. On Databricks Apps, agents use LangGraph checkpointers or the OpenAI Agents SDK, and Databricks handles authentication between the app and Lakebase. On Model Serving, agents use Lakebase-backed checkpoints, and the deployment "Supports LangGraph time travel to resume or fork conversations from any checkpoint." Lakebase is still governed. The use-cases page says agent memory and Lakebase-powered online feature stores "benefit from automatic scaling, scale-to-zero, and Unity Catalog governance."
Checkpoint 2 of 4· Match them up
Match each requirement to the Lakebase capability that meets it
Tap a term, then the definition that fits it.
Long-term memory stores insights across conversations, short-term memory checkpoints a single session, Model Serving checkpoints support time travel, and Lakebase powers online feature stores.
“Extracts and stores key insights across multiple conversations.”Source: docs.databricks.com
Checkpoint 3 of 4· Exam question
A single-agent Databricks system handles a broad, multi-domain workflow (billing, technical troubleshooting, and account changes) in one continuous session. As the conversation spans all three domains, the agent's context grows large and it starts confusing details from one domain with another. The team wants a structural fix, not just better prompting. Which intervention is most appropriate?
Correct answer: A — Split the workflow into specialized sub-agents per domain so each operates over a smaller, focused context
- A. Correct. Moving from a single dynamic agent to a multi-agent architecture lets each sub-agent carry only the context relevant to its domain, structurally reducing the token volume and topic-mixing that was causing cross-domain confusion, which matches the request for a structural rather than prompting-only fix.
- B. Incorrect. Simply allowing a larger window keeps all three domains mixed together in one context, which does not resolve the confusion between domains and can still be degraded by growing, unfocused history.
- C. Incorrect. Combining more instructions into a single larger prompt adds more competing content to the same shared context, which is likely to worsen cross-domain confusion rather than fix it.
- D. Incorrect. Self-summarization changes the output format but does not change what is structurally present in the agent's working context, so the underlying domain-mixing problem remains.
3.Moving data between the lakehouse and Lakebase
Many scenarios involve both tools at once, so learn the two bridges between them. Lakebase supports four patterns, and "Each pattern uses Postgres alongside Unity Catalog". Two of the patterns move data across the boundary, in opposite directions.
| Pattern | Mechanism | Choose it when |
|---|---|---|
| Serve lakehouse data in Postgres | Synced tables (Snapshot, Triggered, or Continuous sync modes) | An app or agent needs Unity Catalog data at low latency |
| Store Postgres changes in the lakehouse | Lakebase Change Data Feed (Public Preview) writes row-level changes as Unity Catalog managed Delta tables | Downstream pipelines, materialized views, or audit queries need the operational history |
| Run an application backend | Standard Postgres drivers, with autoscaling, scale-to-zero, and branching | An application needs its own transactional database |
| Power agents and ML | Agent memory and Online Feature Stores | Agents need conversation state, or served models need feature data |
Data flows inbound through synced tables: "Synced tables bring Unity Catalog data into your Lakebase database for low-latency transactional reads." The pipeline is fully managed. Pick the sync mode for the freshness you need: "Continuous mode keeps data within seconds of the source", while Triggered mode trades some freshness for cost with scheduled incremental updates.
Data flows outbound through Lakebase Change Data Feed, which is in Public Preview. It captures every insert, update and delete from the write-ahead log and "stores row-level changes from your Postgres tables as Unity Catalog managed Delta tables". The capture runs on independent compute, so production queries are unaffected.
This gives the selection rule for mixed scenarios. The analytical copy of record lives in Unity Catalog. The low-latency operational copy lives in Lakebase. A synced table or CDF connects them, so you do not write sync scripts.
Checkpoint 4 of 4· Check yourself
A customer-support agent must look up account tiers from a curated Unity Catalog table during each conversation, within seconds of upstream changes. What is the documented approach?
Synced tables move Unity Catalog data into Lakebase for low-latency reads, and Continuous mode keeps that data within seconds of the source. CDF moves data the other way, from Postgres into the lakehouse.
“Synced tables bring Unity Catalog data into your Lakebase database for low-latency transactional reads.”Source: docs.databricks.com
Sources4
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.Unity Catalog governs tables and files; agent tools and services need a separate permission system.Why is that wrong?
Functions, models, and services, including MCP services, are Unity Catalog securables in the same three-level namespace as tables.
2.Choosing Lakebase for agent memory means giving up Unity Catalog governance, because Lakebase is a separate Postgres database.Why is that wrong?
Lakebase has native Unity Catalog integration, and agent memory and online feature stores built on it are documented as benefiting from Unity Catalog governance.
Covered in Lakebase: where an agent keeps its state
3.Lakebase Change Data Feed is how you get Unity Catalog tables into Postgres for an app.Why is that wrong?
CDF goes the other way: it writes Postgres row-level changes into Unity Catalog managed Delta tables. Synced tables bring Unity Catalog data into Lakebase.
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“Unity Catalog operates beneath every data and AI interaction in your workspaces automatically”
↩︎ Unity Catalog: the layer the other tools sit on“Govern AI assets and AI traffic using Unity Catalog and AI Gateway.”
↩︎ Unity Catalog: the layer the other tools sit on“from source data through to models, services, and dashboards”
↩︎ Unity Catalog: the layer the other tools sit on“Unity Catalog operates beneath every data and AI interaction in your workspaces automatically”
↩︎ Key concept“tables, views, volumes, functions, models, and services (model services and MCP services) follow a three-level namespace (catalog.schema.object)”
↩︎ Exam trap 1“tables, views, volumes, functions, models, and services (model services and MCP services) follow a three-level namespace (catalog.schema.object)”
↩︎ Prediction“tracking lineage as data and AI assets are used, logging activity for auditing”
↩︎ Checkpoint - 2.https://docs.databricks.com/aws/en/oltp/projectsOfficial docs
“Lakebase is a fully managed Postgres database integrated into the Databricks platform.”
↩︎ Lakebase: where an agent keeps its state“Use Lakebase as an online feature store for ML models, or as a state store for agents.”
↩︎ Lakebase: where an agent keeps its state - 3.
“Agents need persistent storage to maintain context across turns and sessions.”
↩︎ Lakebase: where an agent keeps its state“You can implement either or both memory types in the same agent.”
↩︎ Lakebase: where an agent keeps its state“Supports LangGraph time travel to resume or fork conversations from any checkpoint.”
↩︎ Lakebase: where an agent keeps its state“Captures context within a single conversation session using thread IDs and checkpointing.”
↩︎ Prediction“Extracts and stores key insights across multiple conversations.”
↩︎ Checkpoint - 4.
“Each pattern uses Postgres alongside Unity Catalog”
↩︎ Moving data between the lakehouse and Lakebase“Continuous mode keeps data within seconds of the source.”
↩︎ Moving data between the lakehouse and Lakebase“stores row-level changes from your Postgres tables as Unity Catalog managed Delta tables”
↩︎ Moving data between the lakehouse and Lakebase“Both benefit from automatic scaling, scale-to-zero, and Unity Catalog governance.”
↩︎ Exam trap 2“stores row-level changes from your Postgres tables as Unity Catalog managed Delta tables”
↩︎ Exam trap 3“Synced tables bring Unity Catalog data into your Lakebase database for low-latency transactional reads.”
↩︎ Checkpoint