Databricks Ontologies: Genie, OntoBricks & Graph Serving

Relational schemas define where data lives and what data types it uses. AI agents, business intelligence tools, and complex applications need shared business semantics to interpret enterprise data accurately. In the Databricks ecosystem, teams are increasingly asked to build an ontology that provides relational context over lakehouse tables.

Building an ontology requires separating two distinct architectural roles: where business meaning is governed, and where the resulting graph is served, updated, secured, and traversed at runtime. Conflating semantic definitions with operational database infrastructure leads to inflexible architectures and unnecessary sync complexity.

TL;DR

• Genie Ontology combines governed Unity Catalog semantics with inferred business context for Genie One and Genie Code. It is a context layer, not a standalone graph database.

• OntoBricks models explicit ontologies over Unity Catalog data, maps tables using R2RML, validates relationships, applies reasoning, and builds or virtualizes knowledge graphs.

• Choose serving based on the workload. Lakehouse/Delta serves governed analytical snapshots, Lakebase/Postgres supports low-latency reads, and OntoBricks' Neo4j backend provides Cypher-based property-graph access.

• Use an independently integrated operational graph database when applications require graph writes, repeated multi-hop traversal, integration with operational sources, or graph serving outside Databricks. HydraDB provides this layer through a separate publishing and synchronization pipeline.

What is a Databricks ontology?

In the Databricks ecosystem, an ontology represents shared business meaning across data, but the term covers distinct approaches. Genie Ontology combines governed Unity Catalog semantics with inferred organizational context for AI experiences. OntoBricks supports explicit ontology modeling and mapping of Unity Catalog tables into knowledge graphs. Teams can also build custom ontologies using their own semantic models and graph infrastructure.

The distinction between a schema, an ontology, and a knowledge graph is important:

• Schema: Defines the technical structure of stored data, including columns, data types, and keys.

• Ontology: Defines governed business meaning, including entity types, relationships, constraints, and semantic rules.

• Knowledge graph: Represents instantiated entities and connected facts from source data, often using an ontology to define their meaning. A knowledge graph can also contain reasoned facts.

Genie Ontology uses semantic definitions and context to help Genie interpret enterprise questions. An explicit knowledge graph follows a different workflow: source tables are mapped to entities and relationships, then the connected facts are exposed through a graph backend or API.

Consider a sales table in Unity Catalog containing account IDs, product IDs, and transaction amounts. An ontology defines Account, Product, and a Purchased relationship. A materialized knowledge graph contains the instantiated fact that Acme Corp purchased Widget A. The graph exposes that relationship directly to applications rather than requiring each application to reconstruct its meaning from table joins.

Genie Ontology vs. OntoBricks vs. custom ontologies

These approaches all work with business meaning in the Databricks ecosystem, but they solve different problems.

Genie Ontology is Databricks' Public Preview unified context layer for Genie One and Genie Code. Its modeled foundation uses Unity Catalog Metric Views, Pages, and Domains to represent governed measures, business definitions, and asset organization. It also learns context from supported tables, SQL queries, dashboards, notebooks, and other work assets. Genie selects relevant context using authority, relevance, and access permissions. External AI agents can retrieve Genie-powered answers through the Genie One MCP server. Genie Ontology does not expose a standalone RDF triple store or general-purpose graph traversal engine.

OntoBricks is a Databricks Labs source-available project distributed under the Databricks License. OntoBricks creates explicit ontologies using OWL, RDF, SHACL, and SWRL. It maps Unity Catalog tables with R2RML, validates constraints, applies reasoning, and materializes or virtualizes graph data. OntoBricks serves graphs through configured backends, GraphQL, and MCP interfaces. Databricks Labs projects are provided AS-IS without formal Databricks SLAs.

Custom ontologies on Unity Catalog use domain-specific classes, relationships, and business rules with custom mapping pipelines or another standards-based semantic layer. Teams choose how to instantiate the graph, expose its query surface, and synchronize it with source systems.

Why Databricks ontologies matter

Business concepts span tables, departments, and systems. Relational schemas define how data is stored, but do not establish a shared vocabulary for accounts, contracts, suppliers, obligations, and their relationships. Ontologies provide that vocabulary for applications, BI tools, and AI agents.

Centralizing entity definitions and reusable rules reduces the need to reconstruct the same meanings in notebooks, dashboards, APIs, and application code. Constraints and relationship validation also expose missing references, contradictory facts, and semantically invalid records before downstream systems consume them.

Relationship-aware graph context complements vector retrieval by exposing explicit connections between enterprise entities. Agents can use those connections to follow business relationships rather than relying only on textual similarity.

Unity Catalog controls govern source-table permissions, ownership, and lineage. When an instantiated graph moves into a separate database, the serving application must enforce corresponding identity, authorization, and tenant-access controls across that boundary.

How to build a Databricks ontology from Unity Catalog tables

The following workflow applies to explicit ontology and knowledge graph construction with OntoBricks. Genie Ontology uses a different path based on modeled and inferred business context. The OntoBricks getting-started guide provides the product workflow for building and exposing a graph.

1. Create a domain and import source metadata. Select the relevant Unity Catalog catalog, schema, and tables. OntoBricks imports table and column metadata before moving source facts into a graph backend.

2. Define entities, relationships, and rules. Design the ontology visually, generate an editable starting model, or import OWL. Represent business concepts as classes, define relationships between them, and add the constraints and rules that applications should share.

3. Map the ontology to tables. Connect entity identifiers and attributes to source columns using R2RML. Map relationships with queries that return source and target identifiers, and validate those mappings.

4. Choose a backend and build the graph. Select Lakehouse/Delta, Lakebase/Postgres, or Neo4j, then synchronize the mapped entities and relationships into the chosen store. Views-only serving offers a different option when source facts should remain queryable through Lakehouse views.

5. Validate and reason over the graph. Apply SHACL checks to detect invalid relationships or missing required properties. Use OWL and SWRL reasoning where inferred facts are needed. Keep authoritative workflow state in its source system.

6. Publish the serving interface. Expose approved graph data through OntoBricks GraphQL or MCP, or publish it through a separate integration pipeline to an independently managed graph database. Define refresh behavior and access controls for each serving path.

For example, a contract ontology maps accounts.account_id to Account, contracts.contract_id to Contract, and invoices.invoice_id to Invoice. Relationship mappings use contracts.account_id to connect accounts to contracts and invoices.contract_id to connect contracts to invoices. A SHACL rule then checks that each Invoice refers to a valid Contract. OntoBricks can build and validate that graph before an application uses its relationships.

The underlying standards play separate roles: OWL defines the ontology, R2RML maps relational data to RDF facts, SHACL checks data constraints, and SWRL or OWL reasoning derives additional facts. The graph-serving backend then exposes the resulting entities and relationships to applications.

Databricks ontology serving modes with OntoBricks

OntoBricks separates semantic modeling and reasoning from runtime storage and querying. Its built-in graph backends are Lakebase/Postgres, Lakehouse/Delta, and Neo4j. It also supports Lakehouse views-only serving and ontology-only configurations. The OntoBricks architecture explains how the mapping, reasoning, and backend layers fit together.

Lakehouse live-query (views-only) mode

This mode exposes mapped source facts through Lakehouse views rather than copying those facts into a separate graph store. R2RML mapping SQL executes against Unity Catalog tables when source facts are queried, while inferred triples may be stored separately.

An internal BI agent can retrieve the current source status of an order without waiting for a materialized source-triple refresh.

• Advantages: Avoids duplicating mapped source facts, uses current source-table reads, and avoids maintaining a separate database.

• Tradeoffs: Multi-hop access can require expensive SQL joins; the mode does not provide operational graph writes; inferred-fact freshness and source-data freshness can diverge.

Materialized Lakehouse/Delta mode

OntoBricks materializes mapped triples into Delta tables governed through Unity Catalog. This mode supports snapshot analytics and batch data-quality workflows over a built graph.

For example, a data quality pipeline builds a customer graph, checks SHACL constraints, and exposes the validated snapshot to internal analysts.

• Advantages: Keeps the mapped graph in the lakehouse and supports analytical access to a governed snapshot.

• Tradeoffs: Materialized mapped facts reflect the last build, so refreshes require the configured rebuild or synchronization workflow. The query path remains lakehouse-oriented rather than a native property-graph interface.

Materialized Lakebase/Postgres mode

OntoBricks materializes graph triples into Lakebase/Postgres for low-latency reads through its GraphQL and MCP interfaces, reasoning, and BFS or cohort builds. The backend uses a flat triple model and SQL execution rather than a Cypher property-graph query surface.

For example, an internal application can read a customer entity and its mapped relationships through the OntoBricks serving interface.

• Advantages: Provides a Databricks-aligned Postgres serving path and supports application-oriented graph reads without provisioning a separate property-graph engine.

• Tradeoffs: Traversal uses its triple representation and SQL-based execution. Freshness depends on the configured build and synchronization mode.

Materialized Neo4j backend mode

OntoBricks builds ontology-mapped graph data in its Neo4j backend, providing Cypher-based property-graph access outside native lakehouse query paths. This separates ontology governance from a dedicated runtime graph-serving layer.

For example, a customer-facing AI application can query connected account, contract, and invoice data using Cypher patterns.

• Advantages: Supports property-graph traversal patterns and separates graph query serving from Databricks analytics.

• Tradeoffs: Requires an external database, data synchronization, and authorization design across the Databricks and graph-serving boundaries.

No-backend ontology-only mode

This configuration stores ontology assets without selecting Lakehouse, Lakebase, or Neo4j for runtime graph serving. Teams can define Account and Contract classes, relationships, and SHACL rules before choosing how to expose instantiated facts.

• Advantages: Separates ontology design and governance review from backend selection.

• Tradeoffs: Does not provide an instantiated runtime graph for applications. A backend or serving API is still required when applications need graph data.

Databricks ontology serving modes compared

This comparison covers OntoBricks' built-in backends and serving configurations. An independently integrated operational graph database, such as HydraDB, is a separate graph-serving architecture rather than another built-in OntoBricks backend.

When should you use a separate graph database for a Databricks ontology?

Choose the serving architecture based on application access patterns, graph updates, and operational boundaries, not simply on whether the data originated in Databricks. Lakebase/Postgres already provides a low-latency graph read path within OntoBricks. A separate operational database becomes relevant when the application needs different query semantics, ongoing graph mutations, integration with operational systems, or independent runtime scaling.

• Query shape: Determine whether requests are mostly analytical scans and occasional joins or frequent traversals across connected entities. Evaluate traversal depth, fanout, concurrency, and the graph query interface the application needs.

• Update pattern: Separate ontology rule changes from application writes. A graph used as a read-only materialization has different synchronization requirements from one receiving operational entity and relationship updates.

• Freshness: Decide whether a scheduled graph build is sufficient or changes in authoritative systems must reach the served graph continuously. Define how derived facts are recomputed after source changes.

• Source coverage: A graph built only from Unity Catalog tables differs from one joining Databricks-derived facts with CRM, billing, identity, or other operational systems.

• Serving independence: Applications running outside Databricks may require a dedicated database endpoint, isolated capacity, and a query surface that does not depend on a Databricks SQL path for every traversal.

• Security: A separate graph needs explicit identity propagation, tenant filtering, and access-control enforcement. Unity Catalog permissions do not automatically become runtime graph permissions.

HydraDB provides an object-store-native graph database for an independently managed serving layer. An integration pipeline must transform and synchronize ontology-mapped data into HydraDB. Its Bolt connectivity does not make it a drop-in OntoBricks backend, and its OpenCypher support covers a defined subset of the language rather than every Neo4j feature.

Examples of Databricks ontologies

An ontology governs the meaning of entities and relationships. The runtime architecture determines how applications read those relationships and how source changes appear in the served graph.

Customer accounts, contracts, obligations, and invoices

An enterprise stores account hierarchies, contracts, invoices, and financial obligations in Unity Catalog. Its ontology defines Account, Contract, Invoice, and Obligation, together with subsidiary relationships and rules for deriving obligation status from paid invoices. The financial ledger remains authoritative for payment events and effective-dated history.

An explicit graph construction workflow maps the tables to entities and edges, then validates invoice-to-contract references and computes the relevant inferred facts. A separate integration pipeline publishes the validated graph to HydraDB. Because OntoBricks uses RDF triples while HydraDB serves a property graph, that pipeline maps RDF resource identifiers to stable graph node IDs, predicates to relationship types, and literal values to properties. It also handles incremental changes, deletions, and application authorization.

HydraDB then serves relationship queries independently of the Databricks SQL execution path. For example, the following OpenCypher query traverses up to three levels of account subsidiaries, using an illustrative HAS_SUBSIDIARY relationship and numeric Account ID:

```cypher
MATCH (a:Account {id: 101})-[:HAS_SUBSIDIARY*1..3]->(subsidiary:Account)
RETURN subsidiary.id AS account_id
ORDER BY account_id
LIMIT 25
```

The application uses the returned account IDs to find related contracts and obligations in the served graph. HydraDB supports bounded variable-length relationship patterns such as *1..3 in its OpenCypher subset. The example assumes the integration pipeline has created the Account nodes and relationship type; it does not imply that OntoBricks publishes directly to HydraDB.

Semantic data quality with SHACL validation

A healthcare organization maps patient, provider, treatment, and claims tables to an ontology. The ontology defines a relationship requiring each Treatment to reference a valid Provider.

SHACL validation flags missing or invalid Provider links during graph validation before the data is exposed to downstream tools. Applications can consume the validated graph rather than relying on orphaned or semantically incomplete records. The organization still needs to enforce the relevant data access and authorization controls wherever that graph is served.

Conclusion: Serving Databricks ontology graphs with HydraDB

HydraDB provides an operational graph-serving layer for applications built on Databricks ontology data. Databricks and OntoBricks manage semantic definitions, mappings, and validation, while a separate integration pipeline publishes ontology-mapped entities and relationships to HydraDB for independent graph serving and runtime updates.

HydraDB stores durable graph data in S3-compatible object storage and separates query nodes from indexer workers. The HydraDB architecture uses disposable memory and SSD/NVMe caches while keeping object storage as the durable source of truth. Query and indexing capacity scale independently of durable graph storage.

HydraDB supports snapshot-consistent OpenCypher queries, graph mutations, multi-hop path procedures, Neo4j-driver connectivity over Bolt 5.1 through 5.4, and HTTPS query APIs. Applications can access and update the operational graph without depending on Databricks SQL execution paths for each traversal.

To get started, follow the HydraDB graph database getting-started guide. The Cypher compatibility reference defines the supported query patterns for application development.

FAQ

What is the difference between a schema and an ontology?

A schema defines stored structure, such as columns, keys, and data types. An ontology defines business meaning, including entities, relationships, constraints, and rules across multiple tables. An instantiated knowledge graph contains the entities and connected facts mapped from source data.

How do you create an ontology in Databricks?

Use Genie Ontology's modeled Unity Catalog semantics and inferred context for Genie experiences. To construct an explicit ontology and knowledge graph, use OntoBricks to import Unity Catalog metadata, design or generate classes and relationships, map tables through R2RML, select a graph backend, synchronize the graph, and apply validation or reasoning before serving it through GraphQL or MCP.

Does Unity Catalog provide an ontology?

Unity Catalog provides governance and semantic assets such as Metric Views, Pages, and Domains that contribute modeled business context to Genie Ontology. Unity Catalog tables alone do not instantiate a general-purpose RDF knowledge graph. OntoBricks or a custom ontology pipeline performs explicit graph construction over those tables.

Is Genie Ontology the same as OntoBricks?

No. Genie Ontology supplies governed business context for Genie One and Genie Code using modeled and inferred information. OntoBricks is a separate Databricks Labs project for standards-based ontology modeling, mapping, validation, reasoning, and knowledge graph construction.

Does Genie Ontology replace a graph database?

No. Genie Ontology provides business context and Genie-powered answers, including access from external AI agents through Genie One MCP. It is not a standalone graph database or general-purpose graph traversal service. Applications requiring a separately queryable operational graph still need a graph-serving layer.

Which OntoBricks serving mode should I choose?

Use Lakehouse live-query for read-only access to current mapped source facts, Lakehouse/Delta for governed analytical snapshots, Lakebase/Postgres for low-latency reads and reasoning, or the built-in Neo4j backend for Cypher-based property-graph access. Ontology-only mode defers runtime serving. An independent database such as HydraDB requires its own integration and synchronization pipeline.

Can HydraDB serve a knowledge graph built from Databricks data?

Yes. An independent pipeline can publish ontology-mapped entities and relationships from Databricks into HydraDB for OpenCypher queries and application graph updates. The pipeline must map the source graph representation into HydraDB's property-graph model and handle synchronization and security. HydraDB is not a built-in OntoBricks backend.

Is OntoBricks formally supported by Databricks?

OntoBricks is a Databricks Labs project provided as source-available software under the Databricks License. Labs projects are provided AS-IS and do not carry formal Databricks SLAs.