Turn your Databricks tables into a living knowledge graph — in four clicks.
Website · Demos & Screenshots · GitHub · Documentation
Full details are in the Release Notes. |
Every enterprise has the data. Almost none have the meaning. Your Lakehouse stores billions of rows, but nothing captures what they represent — that a Customer holds Contracts, which contain Invoices, governed by rules only your senior engineers remember.
OntoBricks closes that gap. It is a Databricks-native app that turns Unity Catalog tables into an explorable, queryable knowledge graph — design the meaning, let AI map it to your data, and navigate the result visually or expose it to your favorite LLM. No separate graph platform, no RDF expertise, no months-long integration project.
- From schema to graph in minutes, not months. LLM-powered automation drives the whole pipeline — import metadata, generate the ontology, map the data, materialize the graph.
- Lives inside Databricks. Deploys as a Databricks App and reuses what you already have: Unity Catalog, SQL Warehouse, AI Gateway or Model Serving, and Lakebase. Your triples stay in your Lakehouse.
- Standards under the hood, simplicity on top. OWL, R2RML and SPARQL power the engine; everything executes as Spark SQL. Your users never touch RDF.
- Built for the AI era. Publish any domain to LLM agents over the Model Context Protocol (MCP) and let them reason over governed, explainable business semantics.
- Governed by design. Versioned domains, DRAFT → IN-REVIEW → PUBLISHED lifecycle, single-editor locking, and an append-only review audit trail.
- Parse documents once, reuse them everywhere. Uploaded PDF, Office, image, and text sources are parsed into a versioned Knowledge Store (parsed text in Lakebase; originals are not retained) shared by ontology Generate and Mapping; failed parses are visible and retryable.
| Step | Action | What happens | Powered by |
|---|---|---|---|
| 1 | Import Metadata — Domain > Metadata | Fetches table & column metadata from Unity Catalog | Unity Catalog |
| 2 | Generate Ontology — Ontology > Wizard | The LLM designs entities, relationships & attributes from your metadata | AI Gateway / Model Serving |
| 3 | Auto-Map — Mapping > Auto-Map | The LLM generates SQL mappings for every entity and relationship | AI Gateway / Model Serving |
| 4 | Synchronize — Knowledge Graph > Status | Executes the mappings and populates the triple store | SQL Warehouse |
Prefer full control? Every step is also available as a guided manual workflow — design, map, build, query, and reason at column-level precision. See the User Guide.
Selecting No LLM is a strict domain-level opt-out. LLM actions remain visible but unavailable and direct API calls are rejected with guidance to select a model in Domain → General → AI. Select and save an LLM there to make those actions available again without reloading the page. Deterministic reasoning and validation, including OWL/SWRL inference, ontology pitfalls, and SHACL data-quality checks, remain available while No LLM is selected.
Drag-and-drop entities, relationships and inheritance on the OntoViz canvas, or import industry standards in one click (FIBO, CDISC, IOF, HL7 FHIR R4/R4B/R5) and your own OWL/RDFS. A floating AI Assistant edits your ontology through natural language. Catch design issues early with the built-in Ontology Pitfalls Detector (19 structural, logical and semantic checks).
Generate drives that AI design through a resumable, human-in-the-loop wizard — Detect candidate entities from metadata and your parsed document corpus, Review them (include/exclude, edit labels, add your own), then Complete relations, attributes, and axioms in that order. Every run appends to your existing ontology — locked entities are never renamed or removed — and a stale draft (source changed since detection) is flagged with a one-click Re-detect instead of silently reusing outdated candidates.
Let the LLM generate SQL and column mappings for every entity and relationship, then refine with live data preview. Mappings compile to W3C-compliant R2RML you never have to write. Schema-drift warnings flag upstream renames and drops before they break your graph.
Materialize triples incrementally, then reason over the graph with OWL 2 RL inference, SWRL rules and SHACL validation. Explore interactively: two-phase search, N-hop neighbour expansion, cross-domain bridge navigation, community detection (Louvain, Label Propagation, Greedy Modularity), and explainable cohort discovery. Right-click any entity to run its Data Quality Checks (every SHACL shape on its class, its parents and the global ones, with per-dimension gauges), one of its SWRL business rules, or a class action (Unity Catalog function or Databricks Job) — the same checks and actions are MCP tools. Lakehouse domains can optionally read from a Lakehouse//RT query warehouse while builds stay on a classic or serverless warehouse. Query everything through an auto-generated GraphQL API or open Knowledge Graph → Query → SPARQL for read-only SELECT queries, sample queries, CSV export, generated SQL inspection, and triple-shaped results that open in Explorer. See the SPARQL Playground guide, Get Started, and Cohort Discovery.
Expose your knowledge graph to Cursor, Claude Desktop or the Databricks
Playground over the Model Context Protocol.
Each domain decides exactly what it publishes — which tools, which datasets,
which class actions and virtual attributes — right down to ontology-only domains
that expose a single describe_ontology tool. See
MCP Integration.
Every domain version carries a DRAFT / IN-REVIEW / PUBLISHED status enforced server-side. A single editor holds a DRAFT at a time (auto-releasing leases, admin take-over), a business-friendly review workflow collects sign-offs with a configurable quorum, and every decision is persisted append-only. Administrators can safely delete only older, unloaded Draft versions; deletion atomically rechecks Draft status before attempting permanent removal of that version's Knowledge Store content. Cleanup failures are reported as errors rather than false success. Move domains between environments with the OBX export/import (UI or CLI), or mirror every save into the instance's GitHub repository — one commit per save, organised by domain and version, with OWL and R2RML Turtle files alongside the JSON sources (Settings → GitHub).
Pick a backend per domain: Lakebase (Postgres) by default,
Lakehouse (governed Delta triple tables, zero extra infra), Neo4j, or
No Backend for ontology-only domains that publish their ontology with no
graph built (Mapping and Knowledge Graph are disabled and the MCP surface
serves only ontology information).
Connection config stays workspace-global. Lakehouse and Lakebase Build also
materialise Explorer indexes (_adj_out / _adj_in, _entity_search,
_entity_search_asserted, _props); Neo4j keeps native traversal. Full reference:
Lakebase Graph DB ·
Graph DB Integration ·
Graph Query Optimizations.
OntoBricks is not a separate platform. It deploys as a Databricks App and uses the services you already run — Unity Catalog for storage and metadata, a SQL Warehouse for execution, AI Gateway or Model Serving for LLM automation, and Lakebase for the registry and graph store. Your data and your triples never leave your workspace. Architecture deep-dive: architecture.md.
Try it locally
git clone <repository-url> && cd OntoBricks
uv sync --frozen --extra lakebase # install the committed public-PyPI lock
cp .env.example .env # set your Databricks host, token, warehouse ID
scripts/start.sh # open http://localhost:8000Always use --frozen for routine uv sync / uv run commands. The lock
records package indexes as https://pypi.org/simple and immutable artifact
downloads on https://files.pythonhosted.org; do not commit internal
pypi-proxy.dev.databricks.com URLs.
Deploy to Databricks Apps
databricks auth login --host https://<workspace>
# edit scripts/deploy.config.sh (profile, warehouse, registry, Lakebase), then:
make deployPrerequisites (Databricks workspace with Apps enabled, a SQL Warehouse, a Lakebase Autoscaling database, and a Unity Catalog Volume for the registry identifier / export bundles) and the full, idempotent deploy checklist — including one-click graph-DB provisioning and permission bootstrap — are in the Get Started and Deployment Guide.
The bundle syncs only runtime source, the MCP and graph-job files, dependency
locks, and the in-app Help Center set. databricks.yml sync.exclude is
authoritative; .databricksignore is a reviewer/test mirror and is not read
by the Databricks CLI.
The documentation hub groups pages the same way as in-app Help:
- Start here — Get Started · Examples · Feature inventory
- Using OntoBricks — User Guide · Advanced features · MCP
- Platform — Graph backends · Architecture · API
- Deploy & develop — Deployment · Development
- About — Product / value proposition
Product overview, screenshots and videos: ontobricks.org.
OntoBricks, including OntoViz, is source-available under the Databricks License.
Please note that all projects in the /databrickslabs github account are provided for your exploration only, and are not formally supported by Databricks with Service Level Agreements (SLAs). They are provided AS-IS and we do not make any guarantees of any kind. Please do not submit a support ticket relating to any issues arising from the use of these projects.
Any issues discovered through the use of this project should be filed as GitHub Issues on the Repo. They will be reviewed as time permits, but there are no formal SLAs for support.