Timbr’s own product framing has shifted toward calling itself an active, queryable semantic catalog for AI agents: query volume increasingly comes from natural-language and agentic tools, not only SQL clients and BI dashboards. What Timbr ships to support that shift is an ontology built from four typed primitives, not a loose collection of views.
- Concepts are OWL Classes, defined as virtual tables that inherit from a root class called Thing.
- Properties are OWL Datatype Properties, and a primary key is mandatory to map each one to real data.
- Relationships are OWL Object Properties built on foreign keys, supporting transitive depth and inverse naming.
- Inheritance lets a sub-concept automatically pick up its parent’s properties, relationships, and mappings.
| What It Is | Core Mechanism | Query Surfaces | Connectors | Deployment | What Isn’t Independently Verified |
|---|---|---|---|---|---|
| An ontology-based semantic layer modeling business concepts as a virtual SQL Knowledge Graph over existing databases, no data movement | Concepts, Properties (mandatory primary key), Relationships (transitive, inverse-named), Inheritance, via SQL-like DDL | SQL, JDBC, ODBC, REST API, Python SDK, MCP server, LangChain/LangGraph provider, GraphRAG SDK | 40+ sources (Snowflake, Databricks Unity Catalog, BigQuery, Postgres, Oracle, SAP HANA), 20+ BI tools | SaaS (Teams or Business) or self-hosted Enterprise on Kubernetes, VPC or on-premises | Built-in lineage, governance, and “active semantic catalog” status: self-reported, not benchmarked by an outside analyst |
What is Timbr’s semantic layer?
Timbr, the product of WPSemantix Ltd., is an ontology-based semantic layer that models business concepts, relationships, and metrics as a virtual SQL Knowledge Graph laid over an existing database, with no data copied or moved. According to Timbr’s own site, the company was founded in 2018 in Israel by the Weitzner family, with Amit Weitzner as CEO, has raised roughly $3.55 million in seed funding, and runs a team of around 9 to 15 people as of 2026, behind a broad connector list: more than 40 source connectors, including Snowflake, Databricks, BigQuery, Postgres, and Oracle, plus more than 20 downstream BI tools.
The core mechanic separates Timbr from a plain SQL view. Concepts, relationships, and metrics map onto existing tables at query time, so the ontology stays a virtual overlay rather than a second copy of the data that can drift from the source. That puts Timbr inside the broader semantic layer category, but its implementation is ontology-grounded, built on OWL-style classes and properties, rather than the metrics-cube style Cube’s semantic layer or a dbt Semantic Layer uses, a distinction semantic layer versus metrics layer covers in depth. A semantic layer, in either style, defines what a concept means once; a head-to-head across the wider category sits in the best semantic layer tools roundup rather than here.
How those four primitives actually connect, and how a query walks between them without a hand-written join, is where Timbr’s real engineering shows up.
How does Timbr’s SQL ontology actually work?
Timbr’s ontology is built from four primitives, concepts, properties, relationships, and inheritance, expressed in SQL-like DDL and served through five virtual schemas.
Per Timbr’s modeling documentation, a concept is an OWL Class, functioning as a virtual table, inheriting from a root class called Thing. A property is an OWL Datatype Property, requiring a mandatory primary key. A relationship is an OWL Object Property built on a foreign key, supporting one-to-many and many-to-many connections, transitive depth, and inverse naming via INVERSEOF. Inheritance runs through “Is-A” validation: a sub-concept picks up its parent’s properties, relationships, and mappings.
The workflow is SQL-DDL-as-code: CREATE OR REPLACE CONCEPT ... INHERITS (<parent>) defines a concept, CONSTRAINT ... FOREIGN KEY ... REFERENCES ... INVERSEOF ... TRANSITIVE (<depth>) defines a relationship. That’s the differentiator against a plain SQL view: a transitive, typed relationship a generic JOIN can’t express. The payoff shows up in the dtimbr schema below, answering multi-hop questions without a hand-written JOIN chain.
The five virtual schemas
| Schema | What it does |
|---|---|
timbr |
Intrinsic schema, direct concept and property access |
etimbr |
Derived schema |
dtimbr |
Dereferenced graph traversal, no explicit JOINs |
vtimbr |
Views |
gtimbr |
Graph algorithms, add-on license |
Delivery surfaces
Once the ontology exists, Timbr ships it through several surfaces: SQL over JDBC/ODBC, a REST API, a Python SDK, an MCP server Copilot Studio and other MCP clients query directly, a LangChain and LangGraph provider, and a GraphRAG SDK retrieving from the ontology the way GraphRAG retrieves from a connected graph. That breadth answers how to query the ontology, not who owns a concept once several teams and agents pull from it, the question the limitations section takes on next.
Inside Atlan AI Labs and the 5x accuracy factor
See how explicit semantic context, not just a bigger model, closed the accuracy gap in real production systems, with a repeatable playbook behind it.
Get the AI Context StackWhat is Timbr used for?
Timbr’s own case material and product pages point to three real jobs: self-service analytics over an existing warehouse, natural-language and AI-agent grounding, and OEM-embedded semantic modeling inside a third party’s own software.
Self-service analytics over an existing warehouse
Timbr’s self-service pitch is structural: once concepts, properties, and relationships are modeled inside the ontology, self-service analytics access doesn’t require IT to build a new view for every request, because the ontology stands in for the JOIN logic an analyst would otherwise need help writing. AB InBev, Mekorot, and Planview all appear as named customers, though no case study names which uses the ontology this way. Databricks is where Timbr’s native Unity Catalog integration matters most: per Timbr’s own announcement, it exposes the semantic model inside Unity Catalog and the Hive metastore, queryable from a notebook in SQL, Python, R, or Scala.
Natural-language querying and AI-agent grounding
Timbr’s GenAI NL2SQL engine and GraphRAG SDK let the same ontology answer both SQL and natural-language or agent queries, without standing up a separate graph database. The MCP server and LangChain/LangGraph provider are the delivery surface behind that claim, the pattern Cube’s own MCP server gets credit for in a metrics-cube-style layer, applied here to an ontology-style one. That grounding problem sits behind text-to-SQL for enterprise, and text-to-SQL against a semantic layer is the comparison Timbr’s engine sits inside, since the ontology gives text-to-SQL something more structured than a bare schema.
OEM and embedded use
Vistex signed an OEM agreement embedding Timbr’s semantic-graph technology inside its own pricing software, a different shape of adoption than running Timbr directly. Across all three jobs, one caveat holds up: ontology modeling still requires real business-domain expertise. Timbr gives a concept a better home than a spreadsheet or scattered views, but doesn’t remove the work of deciding what a Customer or a Region means, and no ontology tool claims otherwise.
Is your semantic layer actually governed?
Run a quick assessment to see whether the concepts your team defines in Timbr, dbt, or elsewhere are still tracked, owned, and validated once they ship.
Take the AssessmentIs Timbr a knowledge graph or a semantic layer?
Timbr is a semantic layer whose implementation is ontology and knowledge-graph shaped, not a general-purpose stored knowledge graph a dedicated graph database holds on its own. The distinction sits in where the graph lives: Timbr’s ontology is a virtual overlay on existing SQL tables, queryable in standard SQL and exportable to RDF, SPARQL, and Cypher, rather than a separately materialized graph like the ones covered in Amazon Neptune’s own graph-database explainer.
That virtual-versus-stored distinction is general, not specific to Timbr, and it’s covered at the category level in knowledge graph versus data catalog, context graph versus ontology, and ontology versus semantic layer. What Is Stardog? covers the closest analog: another vendor building an ontology and RDF-native product, facing the same virtual-versus-materialized question. What a knowledge graph is at its most basic, and how one gets constructed for AI use, sits above both vendor-specific answers, and the same active-versus-static question shows up in active versus static knowledge graphs.
That virtual-overlay design is also what Timbr’s FAQ leans on for its biggest claim: that the ontology functions as an active, queryable semantic catalog. Teams asking the same virtual-versus-governed question eventually run into Atlan’s Enterprise Data Graph as the governed-graph analog, a thread the closing section picks back up.
What are Timbr’s limitations?
Most single-vendor semantic layers don’t claim this much. Timbr’s FAQ calls its ontology “an active, queryable semantic catalog” with a business glossary, relationships, lineage, and governance controls, including role-based access, row-level security, masking, and encryption. The one hard line it draws: unlike a graph database, Timbr states plainly it “is not a database at all.”
The real limit sits one level up. Those claims are self-described, not benchmarked by an independent audit, and scoped to the concepts and mappings defined inside Timbr’s own ontology. A dashboard, a dbt model, or a raw table Timbr hasn’t mapped sits outside that scope, the boundary any single semantic-layer product runs into once an organization runs more than one tool against the same warehouse.
A second caveat holds regardless of vendor claims: ontology modeling still requires real business-domain expertise. Timbr gives a concept a better structural home than a scattered set of views, but doesn’t remove the work of agreeing what a Customer or a Region means, the same effort any semantic layer or ontology project requires, whether it serves BI dashboards or AI agents.
Scale is the other caveat. Timbr runs roughly 9 to 15 employees and about $3.55 million in seed funding as of 2026, named a Gartner Cool Vendor in 2021 with no Magic Quadrant or Wave placement since, and names customers including Vistex, whose OEM agreement is documented, but hasn’t published a named, credentialed customer quote the way larger vendors do.
| Claim | Verified | Source |
|---|---|---|
| “Active, queryable semantic catalog” with lineage, governance, and a business glossary | Self-described, not benchmarked by an outside analyst or audit | Timbr FAQ |
| Built-in role-based access, row-level security, masking, encryption | Real features, scoped to Timbr’s own ontology, not the wider estate | Timbr FAQ |
| Not a database, unlike a graph database | The one boundary Timbr states explicitly | Timbr FAQ |
That last row is worth sitting with, because semantic layer versus data catalog and data catalog versus context layer both cover the same boundary: a well-modeled ontology answers what a concept means, not who owns it or what breaks downstream when it changes, the accountability gap that shows up whenever semantic layers alone don’t hold up the way a context graph does.
How Atlan approaches governance for semantic layers like Timbr
An ontology that’s genuinely well modeled, with typed concepts, mandatory primary keys, and transitive relationships, can carry real access controls for whatever lives inside it. What it can’t do by definition is extend that governance to the tables, dashboards, and other semantic layers it never mapped. Timbr’s own claims raise this scope question directly, not as a disclaimer but as the hinge into what governs the rest of the estate.
In practice, enterprises running an ontology-based semantic layer like Timbr as their production execution engine are already looking to catalog those ontology objects as first-class, governed assets, and to trace lineage from the warehouse tables through the semantic mappings to the concepts agents and dashboards consume. That’s a pattern seen in production today, and it’s the gap Atlan’s Enterprise Data Graph is built to close: it connects assets, lineage, ownership, and policy into one governed graph above whatever ontology layer a team runs. Atlan ingests semantic-layer and ontology definitions from third-party tools as first-class assets, the same claim made for Cube, dbt, and LookML, without claiming a packaged, native Timbr connector that doesn’t yet exist.
Timbr executes and translates ontology-driven queries; Atlan catalogs context across the data estate that ontology sits inside, the division of labor covered in what the enterprise context layer does, in how to implement one for AI, in how active metadata compares, and in how MCP-connected governance decides what an agent can retrieve regardless of which tool defined the concept. The same pattern shows up on Databricks, where an ontology built on Unity Catalog runs into the identical question, and it’s why context engineering treats a governed concept as infrastructure a team builds deliberately, not an afterthought.
See how Atlan governs concepts wherever they're defined
Watch a live walkthrough of how Atlan's context layer tracks ownership, lineage, and validation status for concepts defined in Timbr, dbt, and beyond.
Watch the Live DemoThe governance question Timbr’s ontology doesn’t answer
What Timbr does well holds up on its own terms: an ontology-grounded, SQL-native semantic layer genuinely useful for self-service analytics and AI-agent grounding, with a typed modeling approach most competing tools don’t match, and at least one verifiable customer relationship in Vistex’s OEM agreement. Its lineage and governance claims hold up too, as far as they reach: real features, by Timbr’s own account, scoped to the ontology it models, not independently benchmarked.
A well-modeled ontology still needs something governing what gets cataloged, traced, and trusted once it leaves the semantic layer and reaches an agent or a dashboard, especially the parts of the estate no single semantic layer ever mapped. That question sits above the ontology engine, not inside it, regardless of which vendor built it.
FAQs about Timbr’s semantic layer
1. What is Timbr used for?
Timbr is used to build a single ontology-based semantic layer over an existing warehouse, so self-service analytics, natural-language queries, and AI agents read the same concept definitions. AB InBev, Mekorot, and Planview appear as named customers, and Vistex has gone further, signing an OEM agreement embedding Timbr’s technology inside its own pricing software.
2. Is Timbr a knowledge graph or a semantic layer?
Timbr is a semantic layer whose modeling approach is ontology and knowledge-graph shaped. It builds a virtual graph overlay on existing SQL tables rather than a separately stored graph, staying queryable in standard SQL while also exporting to RDF, SPARQL, and Cypher.
3. Is Timbr open source?
No. Timbr is delivered as a commercial SaaS product on Teams and Business plans, both with a 14-day free trial, or as a self-hosted Enterprise deployment on Kubernetes for teams running it inside their own VPC or on-premises.
4. How does Timbr’s SQL-to-knowledge-graph translation work?
Timbr models a business domain as concepts, properties, relationships, and inheritance, defined through SQL-like DDL statements such as CREATE CONCEPT and FOREIGN KEY … INVERSEOF. That ontology sits as a virtual layer over the source tables, so a query translates into the underlying SQL at query time, without copying the data.
5. Does Timbr replace a data catalog?
Timbr’s own FAQ claims the opposite: it describes its ontology as an active, queryable semantic catalog with lineage and governance built in. That claim is self-described, not benchmarked by an independent audit, and it only covers concepts and mappings defined inside Timbr. Cataloging the wider data estate is still a separate job.
6. Can Timbr connect to Snowflake and Databricks?
Yes. Timbr connects to more than 40 sources over JDBC and ODBC, including Snowflake, Databricks (native Unity Catalog and Hive metastore support), BigQuery, Redshift, Postgres, Oracle, and SAP HANA, and serves the ontology to Power BI, Tableau, Looker, and Excel.
7. Does Timbr support natural-language querying?
Yes. Timbr’s GenAI NL2SQL engine and GraphRAG SDK let an agent query the same ontology in natural language, and its MCP server and LangChain/LangGraph provider ship as concrete delivery surfaces, including Microsoft Copilot Studio integration.
8. What are Timbr’s limitations?
Timbr’s own FAQ claims built-in lineage, governance, and an active, queryable semantic catalog, self-described and not independently audited, scoped to what’s mapped inside Timbr’s ontology. Building it still requires real business-domain modeling work, and Timbr runs as a small, seed-funded vendor: about 9 to 15 employees, one 2021 Gartner Cool Vendor mention, and no named customer quote with a title attached yet.
Sources
- Timbr FAQ (Timbr.ai)
- Timbr modeling documentation (docs.timbr.ai)
- Timbr integration documentation (docs.timbr.ai)
- Timbr pricing page (Timbr.ai)
- Timbr homepage (Timbr.ai)
- LangChain’s Timbr provider docs (docs.langchain.com)
- Introducing Timbr SQL-KG (Timbr.ai blog)
- The Context Layer Data Agents Need (Timbr.ai blog)
- RDF Graph Materialization (Timbr.ai)
- GenAI NL2SQL Engine (Timbr.ai)
- Timbr GraphRAG (Timbr.ai)
- Ontology-driven Data Agents for Databricks (Timbr.ai news, 2026-05-05)
- Timbr named a Gartner Cool Vendor (Timbr.ai blog, 2021)
- Timbr and Vistex OEM agreement (Timbr.ai news, 2021-12-17)
- Timbr.ai partners with Databricks announcement, Timbr.ai blog
