I recently attended the Databricks Data + AI World Tour in Singapore, held on September 16 at the Marina Bay Sands Expo & Convention Centre. Singapore was one of the tour's first stops in 2026, with the global tour spanning 20 cities.
I have attended a fair number of technology sessions over the years, and one thing stood out immediately: the event was extremely well managed.
From registration and navigation between sessions to the pacing of the agenda, partner areas, technical discussions, and networking, the experience felt very deliberate. There was enough happening throughout the day to keep moving between topics without making the event feel chaotic.
What I found more interesting, though, was how connected many of the product discussions felt.
There were several individual announcements and capabilities to absorb, but I came away thinking about four larger themes:
- Real-time analytics is becoming part of the core Lakehouse architecture
- Business context is becoming a first-class layer for AI
- Genie is moving closer to becoming the business user's entry point into Databricks
- AI governance is expanding beyond models into agents, tools, traffic, and cost
The two areas that interested me most were Lakehouse//RT and Genie Ontology.
They solve very different technical problems, but together they point toward where the Databricks platform is heading.
A world tour that feels like a continuation of the Summit story
The World Tour itself is a large series. Databricks announced 20 cities across North America, Europe, Latin America, and Asia Pacific.
The underlying theme is familiar if you have been following Databricks closely over the last year: getting enterprise AI from experimentation into actual production environments.
In addition to serving a model, the supporting platform now needs to handle:
- governed enterprise data
- real-time workloads
- semantic context
- natural-language interfaces
- agent access
- model governance
- security
- cost controls
- applications used directly by business teams
Many of the sessions and conversations during the day connected back to those layers.
Lakehouse//RT was one of the most notable developments
Databricks describes Lakehouse//RT as serverless compute designed for low-latency and high-concurrency workloads. It targets use cases such as operational analytics, application serving, and BI experiences where hundreds or thousands of concurrent users may require sub-second SQL responses. It can query Unity Catalog tables using Delta Lake or Apache Iceberg directly in cloud storage. The capability is currently in Beta.
For years, Lakehouse discussions have mainly centered on consolidating analytical workloads onto an open data foundation. Real-time application serving, however, often required separate architecture. You might process and govern the data in the Lakehouse, then copy or synchronize a subset into another serving database because the application requires very low latency.
Lakehouse//RT starts to change that equation.
Consider a simple architecture:
If the same governed data can support high-concurrency, sub-second analytical reads, organizations may have fewer reasons to maintain another serving copy solely to meet analytical latency requirements.
That becomes especially interesting for:
- operational dashboards
- customer-facing analytics
- embedded analytics
- real-time recommendation experiences
- AI agents that need fresh analytical context
- applications built directly on Databricks
I would still evaluate workload characteristics carefully before changing an architecture around it. Lakehouse//RT remains in Beta and its supported feature set and performance characteristics can continue evolving.
The direction itself is very interesting.
Databricks is pushing the Lakehouse further into workloads that historically needed another serving layer.
Genie Ontology may have even bigger long-term implications
The other topic I kept thinking about after the event was Genie Ontology.
Anyone who has implemented conversational analytics in an enterprise quickly discovers that tables and column descriptions only explain part of the business. The real context lives everywhere.
- What does an "active customer" actually mean?
- Which revenue definition should Finance use?
- Which dashboard is authoritative?
- Which metric is certified?
- Does FY26 mean calendar 2026?
- Which Genie Agent should answer a particular domain question?
- Which source should win when two definitions conflict?
This information usually exists already, but it is distributed across dashboards, SQL queries, metric definitions, documentation, BI assets, and the knowledge of individual teams.
Genie Ontology is Databricks' approach to building a shared business context layer around that information.
Databricks currently describes Genie Ontology as a unified context layer for the Genie family. It combines two categories of context:
- Unity Catalog semantics, including modeled and governed concepts such as metric views, domains, and other curated assets.
- Inferred context, which Genie can derive from existing assets and usage such as metric views, dashboards, SQL queries, and Genie Agents.
The inferred snippets can represent things such as:
- metric definitions
- business rules
- authoritative sources
Databricks also describes authority scoring based on factors such as source, usage, and freshness, with Unity Catalog permissions determining which snippets a user is allowed to access.
This is an important direction for enterprise AI.
Why ontology matters for enterprise AI?
Models are already capable of generating SQL, summarizing results, and reasoning over data.
Enterprise accuracy frequently depends on whether the system has the right business context at the moment it answers.
Imagine the question:
- "What is our active customer growth this quarter?"
The phrase "active customer" may sound straightforward but inside an enterprise it could mean:
A customer who has placed at least one completed order during the previous 90 days, excluding internal accounts and test transactions.
Another department may use a different definition.
An AI system needs more than schema awareness to resolve that correctly.
It needs an understanding of:
That is why I think the ontology discussion was one of the most important parts of the event. It moves the enterprise AI conversation toward context architecture.
Databricks also has a dedicated session on what it calls the "AI Context Gap," including how Genie Ontology builds and uses a living context graph of business terms, entities, and KPIs.
Genie One brings the experience closer to business users
Databricks describes Genie One as a simplified interface for business users. It provides a common place to interact with dashboards, ask natural-language questions, and use Databricks Apps without requiring users to navigate concepts such as notebooks, models, queries, or compute.
A typical Databricks enterprise environment with interfaces like SQL, Notebooks, Dashboards, Apps, Genie Agents, ML / AI workloads make sense to technical users. A business user, or a non-tech user generally wants to start with a question or task. Genie One gives Databricks a much simpler front door for that audience.
The relationship between Genie One, Genie Agents, and Genie Ontology becomes particularly interesting.
A simplified way to think about it is:
That architecture makes the role of context much clearer. Genie Agents can remain domain-specific while common enterprise knowledge can increasingly be discovered and reused through a broader ontology.
Unity AI Gateway completes another part of the production story
The event also reinforces the importance of AI governance as organizations deploy more models and agents. Databricks has been expanding this area through Unity AI Gateway, acting as the enterprise governance layer for AI interactions.
It governs traffic between applications, agents, models, MCP servers, and tools while providing centralized controls for access, usage, policies, routing, and spend, making it increasingly important as teams move from a single model endpoint to a portfolio of AI services.
An enterprise may have:
- Claude
- GPT
- Gemini
- Databricks-hosted models
- External model providers
- MCP servers
- Internal agents
- Coding agents
- Custom applications
Unity Gateway provides a centralized point where those interactions can be governed.
Making the platform story increasingly cohesive, Databricks also supports routing coding agents such as Claude Code, Codex CLI, Cursor, and Gemini CLI through governed model services, with capabilities like rate limiting, usage tracking, and inference logging.
These capabilities solve different problems, but they fit into the same enterprise architecture.
Key Takeaway: Context is now part of the platform
If I had to summarize the day in one word, I would choose context.
Lakehouse architectures provide enterprises with a governed data foundation, while Metric Views create reusable semantic definitions. Genie Agents allow teams to configure domain-specific business knowledge, and Genie Ontology expands that into an enterprise-level context layer. Genie One gives business users a simpler way to consume this context, while Unity Gateway governs how AI systems access models and tools. Together, these capabilities make governed analytical data increasingly available to latency-sensitive applications through Lakehouse//RT.
Put those pieces together and the architecture starts looking like this:
This was probably my biggest takeaway from Singapore.
The Databricks conversation is expanding from storing and processing enterprise data toward providing the data, semantics, context, serving layer, interfaces, and governance required to build production AI systems around that data.
A word on the event itself
Technical content aside, I also want to give credit to how the Singapore event was organized.
For a one-day event with a large audience, the movement between sessions, networking, partner conversations, and the overall schedule worked extremely well. There was enough variety for people approaching Databricks from different angles, including data engineering, analytics, AI, governance, and architecture.
I also appreciated that many discussions were grounded in what enterprises are trying to put into production now. That makes events like this more valuable than simply reading release notes.
You get to hear the product direction, see the architecture being connected across different sessions, and then discuss those ideas with the people implementing similar systems.
What to watch out for next
There are three areas I will be following especially closely after the event.
1. Lakehouse//RT
I want to see how far Databricks can push sub-second analytical serving directly from governed Lakehouse data, and which serving architectures it can simplify as the product matures.
2. Genie Ontology
This may become one of the more important components of the Genie architecture as enterprises build larger numbers of domain Agents and need business context that can be reused across them.
3. Genie One
As Genie One becomes the business-facing surface across dashboards, natural-language analytics, and Databricks Apps, it could significantly change how non-technical users experience the Databricks platform.
Closing thoughts
My first Data + AI World Tour Singapore was a very useful day, and I was glad to experience it while representing Syren. I went in expecting a set of product sessions. I came away thinking much more about how the different pieces of the Databricks platform are beginning to connect.
For me, the two standout areas were Lakehouse//RT and Genie Ontology.
Lakehouse//RT pushes the Lakehouse closer to real-time application serving. Genie Ontology tackles one of the hardest problems in enterprise AI: giving AI systems governed business context to understand how an organization operates.
Add Genie One, Unity Gateway, Unity Catalog, Metric Views, and the wider agent ecosystem, and the direction becomes much easier to see.
There is a lot to experiment with over the next few months. And after seeing some of these capabilities discussed in Singapore, I already have a few ideas I want to build.
