Frequently Asked Questions

Timbr Intelligent Semantic Layer is an ontology-based semantic layer that serves as a semantic context layer for enterprise AI and analytics systems. It sits virtually above existing data sources, modeling business concepts, relationships, and rules directly in SQL, enabling users to query complex multi-source data without writing JOINs.

Palantir Foundry delivers a powerful operational ontology, but it’s a closed, all-or-nothing world: you ingest and re-platform your data into Foundry, adopt Foundry’s tooling, and accept heavy services-led implementation and cost. The ontology is good, it’s just inseparable from the platform. Timbr positions itself directly here as the open, efficient alternative to Palantir Foundry. It’s a layer you add, not a platform you migrate onto.

Stardog is an RDF/OWL graph database. The ontology is open and standards-rich, but you load data into the graph store, a separate database to populate and maintain, and you query with SPARQL, which needs semantic-web specialists.

Timbr is a SQL-native ontology that runs as a virtual semantic layer on top of the customer’s existing databases. No migration, no separate graph store, no SPARQL requirement. The customer models business concepts and relationships once, and Timbr compiles ontology traversals into optimized SQL pushed down to the source, so queries run at native database speed. It’s knowledge-graph reasoning and GraphRAG without standing up a graph database.

In short: Palantir makes you move your data, Stardog makes you copy it into a graph, Timbr leaves it where it is and puts the meaning on top. No Timbr competitor combines cross-platform virtualization + a SQL-native ontology + agent-ready context in one layer, which is the white space for a multi-source enterprise that can’t consolidate onto one platform.

On “data catalog” specifically: Timbr isn’t a passive inventory catalog like Collibra or Atlan. The ontology is an active, queryable semantic catalog, business glossary, relationships, lineage, and governance are inherent to the model, and unlike a passive catalog, you can run queries and power agents against it. Timbr can leverage that catalog metadata, its business glossary and existing mappings to accelerate ontology generation. It complements a catalog where one exists, or serves as the semantic backbone where one doesn’t.

Yes. AI agents can connect to Timbr in two ways. First, agents and AI platforms such as Databricks can connect directly to the SQL ontology via JDBC/ODBC or REST API, giving them governed, semantic access to business concepts and relationships. Second, agents can connect directly to a configured Data Agent in Timbr, which provides a ready-made semantic interface without requiring additional setup.

Timbr provides the structured semantic foundation that AI and machine learning systems depend on. By modeling business concepts, relationships, and rules as a SQL ontology, Timbr enables accurate NL2SQL query generation, powers GraphRAG retrieval, and gives AI agents governed, consistent context to reason over enterprise data.

Core strength is structured and semi-structured data across relational databases, warehouses, lakes, and platforms like Databricks, Snowflake, and Microsoft Fabric. For unstructured data, Timbr is the semantic backbone, not a document store or NLP extraction engine: the ontology provides the structured context that grounds retrieval over unstructured content. This is the GraphRAG story, and Timbr powers scalable GraphRAG and LangGraph agent workflows. Entities extracted from documents can be modeled as concepts and linked into the ontology.

In short: structured/semi-structured natively; unstructured handled through ontology-grounded context and GraphRAG, typically alongside vector/RAG components rather than replacing them.

Timbr is named after Tim Berners-Lee, who together with Timbr’s advisor Jim Hendler pioneered the Semantic Web. The vision behind Timbr is to bring that same principle of connected, meaningful data into enterprise SQL environments, making data accessible based on business meaning rather than physical structure.

Timbr can be deployed on cloud or on-premises. Computing power requirements depend on application size:

1. Computing power depending on the application size:
   • Small/Medium: 4 CPU 16 GB RAM server
   • Large: 8 CPU 32 GB RAM server
2. Deployment options (Docker or Kubernetes): Linux image or automatic deployment via docker-compose can be installed on any Linux server. You can extend the YAML to add your security protocols, configurations, and customizations.
3. Platform requirements: List of databases with type and version information to validate connectors. Timbr MySQL metadata DB (mandatory – configurable as a container or managed externally).

For full deployment architecture including multi-cloud and agent-based options, see the Timbr Deployment Architecture documentation.

• Core: a virtual SQL ontology engine, effectively a SQL compiler/query-rewriter that turns ontology traversals and path expressions into optimized SQL pushed down to the source.
• Runs on top of: SQL data platforms including Databricks, Snowflake, and Microsoft Fabric, and the broader SQL ecosystem. Timbr connects to enterprise knowledge repositories, data warehouses, and data lakes, with native integration to Apache Spark SQL, R, Python, Java, and Scala. It sits above the database; it doesn’t replace it.
• Deployment: cloud, on-prem, or hybrid.
• Interfaces: standard SQL via JDBC/ODBC, semantic/REST APIs and a metrics store, and notebook access (Jupyter/Zeppelin). It also exposes governed SQL measures, OLAP-style cubes, a SQL Metrics Store, semantic APIs, NL2SQL, and GraphRAG/agent workflows.
• Interoperability: OWL import and RDF materialization to bridge to triplestores and reasoners.

Data lineage is built into the Timbr platform, mainly for impact analysis and visibility between the ontologies (semantic layer), the source systems, and the consumption tools. Timbr has built-in enterprise-grade access management and security controls including RBAC, RLS, Data Policies, Data Masking, and Data Encryption, supporting any type of authentication (SSO, OAuth, JWT, etc.). Integration with Active Directory enables automatic sync with roles and groups. Timbr also includes user impersonation and token passthrough, so customers that already have security policies in the data source layer can decide whether to manage access and security in Timbr as the data access layer, or continue managing it on the database layer.

There is no community version of Timbr, but any organization with a use case in mind can explore the platform through a live demo or a guided proof of concept.

Timbr is virtual because it sits above your existing data sources without moving, copying, or transforming any data. Rather than requiring a physical data layer or ETL pipelines, Timbr’s ontology-based semantic layer maps business concepts and relationships directly to your underlying tables, resolving queries at runtime across all connected sources regardless of where they live. Learn how Timbr’s data virtualization engine works.

A semantic layer simplifies data modeling by turning raw data into consistent business concepts, relationships, and rules. It reduces SQL complexity, unifies data across sources, and ensures consistent metrics for analytics and AI.

Semantic modeling with Timbr enables shorter SQL queries by replacing joins with explicit relationships, consistent metrics and definitions across tools and teams, and virtual data integration without moving or duplicating data. The result is faster analytics delivery, simpler data access for BI tools and AI systems, and a governed model that evolves with your business. Learn more about Timbr’s ontology-based semantic layer.

Timbr’s GenAI NL2SQL Engine transforms enterprise data into a structured, understandable format for large language models, enabling accurate and explainable SQL generation. Because business concepts, relationships, and metrics are explicitly defined in the SQL ontology, LLMs can generate correct SQL without inferring JOIN logic or guessing table structures. Every generated query is traceable back to the originating concepts and metadata, enabling validation and compliance across AI workflows.

The SQL Ontology, as the foundation of a Knowledge Graph, provides any LLM the semantic and technical context for accurate data retrieval. Using the relationships the ontology defines, LLMs can perform Graph Traversals in SQL and focus on the user’s intent rather than the complexity of the query when doing NL2SQL translation. This is part of Timbr’s patent technology – book a demo to see it in action.

Timbr’s SQL metrics store centralizes business metrics such as revenue, conversion rates, and KPIs as governed definitions in the SQL ontology, reused consistently across every BI tool, query, and AI system. Metrics are inherited across relationships, eliminating duplication, and combined with Timbr’s 4-tier cache for high-performance multi-dimensional analysis without data transformation or additional infrastructure.

Building a Timbr semantic layer typically takes days, not weeks. Teams can quickly model business concepts and relationships in SQL, enabling fast initial setup and continuous iteration as requirements evolve.

A SQL Knowledge Graph is the connected data structure that a SQL ontology creates above your existing databases, representing business concepts, relationships, and hierarchies in a way that can be queried directly using standard SQL. It enables data teams to navigate and analyze data based on meaning rather than physical table structure, without requiring any changes to the underlying infrastructure.

A SQL Knowledge Graph is used to integrate, analyze, and explore data across sources without moving or transforming it. By modeling business concepts and relationships directly in SQL, it simplifies queries, enables graph traversals, and delivers consistent analytics across BI tools, AI systems, and applications.

Unlike graph databases, Timbr is not a database at all. It is an ontology-based semantic layer that sits virtually above your existing data warehouses and data lakes, adding semantic graph capabilities without requiring data movement, new infrastructure, or new skills. Graph databases store data in a graph format. Timbr models relationships over data that stays exactly where it is.

Property graphs use proprietary query languages and graph-native storage, which means they cannot be directly converted to a SQL knowledge graph. However, if your underlying data lives in a SQL-compatible data warehouse or data lake, Timbr can build an ontology-based semantic layer directly on top of it, giving you semantic graph capabilities without migrating away from your existing infrastructure. Book a demo to discuss your specific setup.

Creating a SQL Knowledge Graph is a straightforward process:

1. Connect your databases to the virtual layer using JDBC connectors.
2. Model the SQL ontology visually or using Timbr SQL DDL statements, or import from other sources such as data catalogs, OWL ontologies, or ERD tools.
3. Map the ontology concepts to the data.

Once set up, your SQL Knowledge Graph is ready to deliver insights via SQL queries, graph data exploration, BI tools, or Timbr’s embedded charts and dashboard module.

No. Timbr is designed for data teams of all levels. You just need a database. The platform guides you through connecting your data, modeling the ontology, and mapping concepts, with both visual and SQL DDL options available. Book a demo to see it in action.

Timbr’s Graph Data Exploration module lets users visually navigate the concepts and relationships defined in the SQL ontology. Instead of writing queries, users can click through connected concepts, discover relationships, and answer complex business questions through an interactive graph interface.

Data Graph Exploration is a Timbr feature that automatically transforms non-graph data into a virtual graph, allowing users to visualize and explore data relationships as a network. Data consumers, business analysts, and domain experts can discover insights and answer questions without writing any code. Try the demo here.

An ontology is a structured model that defines the concepts, relationships, hierarchies, and rules within a domain, enabling both humans and systems to understand and reason over data based on meaning rather than structure. In enterprise data environments, ontology-based data modeling provides the semantic foundation that makes data consistently interpretable across tools, teams, and AI systems. Timbr implements ontologies as SQL ontologies, making them directly queryable using standard SQL.

The honest answer isn’t “you can’t” – it’s “you should, and Timbr has that built in.” AI-driven ontology generation is a first-class Timbr capability in both directions: bottom-up, AI-driven modeling that connects to existing schemas and generates ontology candidates, and top-down modeling with SQL DDL, LLM-assisted ERD translation, or OWL import. The platform lets AI accelerate ontology creation by proposing concepts, relationships, metrics, and mappings from source data, while the team stays in control of validation, refinement, and governance.

What a raw LLM on its own can’t do is the part after the draft:

• Bind the model to real schemas – map “Customer” to the seventeen tables across four systems where customer data actually lives.
• Guarantee correctness – LLM output is non-deterministic and will hallucinate relationships that don’t exist in the data; a risk or decisioning context can’t run on “probably.”
• Enforce governance and access at query time.
• Compile to optimized pushdown SQL so queries run fast against the source.
• Stay correct as schemas drift – a one-shot LLM gives a snapshot; an ontology has to be maintained and re-validated.

In short: the AI proposes the ontology, the human validates and governs it, and the platform turns it into something deterministic, executable, and durable. Timbr is what makes the AI-generated draft trustworthy – you wouldn’t ask an LLM to be your database.

Humans bring the meaning: a domain/business expert defines the concepts, business terms, and relationships that matter; a data engineer identifies and connects the sources; a governance owner sets who can access what.

The platform does the mechanical and risky parts: it generates a starting ontology with AI (bottom-up from existing schemas), maps concepts to physical schemas, validates that the paths actually connect to real data, compiles concept traversals into optimized SQL, enforces access at retrieval time, and serves results to SQL clients, BI tools, applications, and AI agents.

The division of labor: humans own what things mean and sign off on the AI’s proposals; the platform owns making that meaning true, fast, and governed against live data.

How they build it: through a visual modeler, SQL-style DDL statements, AI-generated candidates from existing schemas, LLM-assisted ERD translation, or OWL import, whichever fits. The domain expert maps business concepts to existing tables and columns. No data is moved.

Where it resides: the ontology and its mappings live in Timbr’s metadata layer as a virtual semantic model. The data stays in the source systems; Timbr stores the model and mappings and rewrites queries against the sources. It deploys cloud, on-prem, or hybrid, relevant for a regulated FS environment.

How it’s accessed and by whom: via standard SQL over JDBC/ODBC, semantic/REST APIs, BI tools, and notebooks. Timbr connects to BI tools via JDBC/ODBC and supports querying from Zeppelin and Jupyter notebooks in SQL, Apache Spark, Python, and R. Consumers are analysts, dashboards, applications, and AI agents needing governed context. (Access is through SQL, not SPARQL, that’s the core design choice.)

Time to create: scope-dependent, but because there’s no ETL/migration underneath, a focused domain ontology is typically days to a few weeks, not months.

Response time: because graph traversals run as standard SQL queries without explicitly writing joins and compile to optimized SQL pushed down to the source, runtime is essentially native-database performance, no separate ETL latency or graph-store round-trip. Semantic caching accelerates repeated and aggregated queries further.

Conceptual modeling is the process of defining business entities, their relationships, and rules in a way that reflects real-world meaning rather than database structure. It provides a shared understanding of data across teams, making it easier to model, query, and analyze consistently.

Knowledge representation is the field of artificial intelligence focused on structuring information so both humans and systems can understand what things mean, how they relate, and how they can be reasoned over. In data environments, this means defining business entities, relationships, hierarchies, and rules explicitly rather than leaving meaning scattered across table names, joins, and application logic.

In SQL ecosystems, knowledge representation is enabled through an SQL ontology – an ontology-defined semantic model that captures business meaning and exposes it through standard SQL, making data consistently interpretable across tools, teams, and AI systems.

SQL ontologies define business concepts, relationships, hierarchies, and rules directly in SQL, creating a semantic layer on top of your data. Unlike traditional schemas, they capture real-world meaning, enabling simpler queries, consistent data integration, and governed access across analytics and AI systems.

An SQL ontology defines concepts like Customers, Orders, and Products, along with relationships such as “customer places order” or “order contains product.” These relationships are modeled directly in SQL, allowing users to query business concepts without writing complex joins.

Timbr offers a visual ontology modeler as well as a SQL DDL editor to model the ontology directly. Concepts can be generated from the database schema, data catalogs, or by importing existing OWL ontologies.

Timbr offers a visual data mapper to manually or semi-automatically select tables and columns from the database, as well as the option to use SQL DDL statements directly. Timbr can filter, clean, and transfer mapped data to the ontology without requiring ETL operations.

Direct ontology creation with semantic normalization built in, not a separate ETL/normalization engine. You map heterogeneous, un-normalized sources to the ontology, and the mapping layer reconciles them at query time, so consumers see one consistent semantic model regardless of how messy the sources are. When performance or external interoperability calls for it, Timbr can materialize into one of four cache tiers.

Yes. Timbr supports applying rules to concepts to classify data or embed business logic directly in the ontology model.

For example: Adult: Person where age > 21 ExpensiveProduct: Product where price > 1000

No separate entities are needed. With Timbr, multiple tables from different data sources can be mapped to the same concept, allowing users to leave their data wherever it is and use Timbr’s ontology modeling tool to map data from various sources to a single unified concept.

In Timbr, virtual PKs serve as unique identifiers for concepts, and FK-to-PK relationships define how concepts connect across the ontology model. By mapping physical table PKs to ontology PKs once, and defining relationships using FK statements, users never need to reconstruct these connections through joins in individual queries – the relationships are already built into the model.

In Timbr, relationships substitute complex JOIN statements so SQL queries become significantly shorter and easier to understand. They represent defined connections between two concepts, matched by the properties of each concept, and are declared once in the ontology rather than reconstructed in every query.

Timbr supports the following relationship types:

• One-to-Many: one instance of a concept may be linked to many instances of another concept
• Many-to-Many: many instances of one concept may be linked to many instances of another, formed from a linked table with two foreign keys
• Transitive: chains connections across multiple concept levels, allowing queries to traverse hierarchies without explicitly navigating each intermediate step

In Timbr, inheritance allows child concepts to automatically receive the properties and relationships of a parent concept. A concept like Alcoholic Drinks defined as a child of Beverage inherits all of Beverage’s attributes without needing to redefine them, keeping the ontology model clean and eliminating duplication across related concepts.

Example of inheritance relationship:

In Timbr, a transitive relationship enables inference by chaining connections between concepts across multiple levels. Rather than writing queries that explicitly navigate each intermediate step, the relationship is defined once in the ontology and Timbr resolves the full chain automatically.

Example of transitive relationship and reasoning:

Yes. Timbr fully complies with OWL DL and its SQL re-write engine functions as an inference engine, automatically generating queries based on inference rules including inheritance, transitivity, and others. Inference can be defined through Timbr’s visual interface or via SQL statements. Timbr also goes beyond OWL by enabling business logic through SQL and expressing aggregations as ontology concepts – capabilities not available in standard OWL.

Yes. Timbr is compatible with OWL-DL and some OWL-2 inferences. Additional OWL-2 inferences can be supported where there is clear business value. Timbr’s inference engine is based on query-rewriting techniques, and where performance requires it, Timbr can selectively materialize the relevant parts of the knowledge. Learn more about Timbr’s OWL ontology support.

Timbr is SQL-native, not RDF-native. It implements the capabilities of semantic-web ontologies – concepts, relationships, hierarchies, inheritance, and run-time inference – in standard SQL, specifically so customers don’t have to adopt triplestores or SPARQL. SQL Ontologies use standard SQL to implement the key capabilities of Semantic Web ontologies, eliminating the need to add database infrastructure, move data, or run ETL into RDF triples.

They interoperate with the semantic-web stack through two bridges, rather than being built on it:

• OWL import – import OWL ontologies, including classes, properties, hierarchies, and restrictions, and transform them into SQL-native semantic models with no data duplication.
• RDF materialization – define the model once in standard SQL and materialize it into RDF/OWL triples, compatible with Protégé, TopBraid, any triplestore, SHACL validators, and reasoning engines.

In short: standards-compatible (RDF/RDFS/OWL via import and materialization), but queried and governed in SQL.

Hierarchies: Timbr supports multi-level hierarchies, transitive inheritance and multiple inheritance. A concept can inherit from more than one parent where this is semantically valid. It is therefore not limited to the shallow dimension hierarchies associated with some traditional BI semantic layers. In practice, hierarchy design should still be governed for clarity and maintainability.

Timbr implements the Semantic Web in SQL, maintaining a direct correspondence between OWL ontologies and SQL ontologies that enables seamless transformation. Concepts, relationships, and inference rules defined in OWL are mapped to their SQL ontology equivalents, allowing organizations to migrate from OWL-based systems without losing semantic richness. Contact us to discuss your OWL migration.

Yes. Timbr is transparent to the SQL user and uses the same dialect and syntax as the underlying database. You can add hints and use all underlying database functionality directly through Timbr’s semantic SQL.

Yes. Timbr is accessible via JDBC/ODBC and the ontology can be created or modified programmatically using Timbr SQL DDL statements:

CREATE CONCEPT (extension of CREATE TABLE statement)

CREATE MAPPING (extension of CREATE VIEW statement)

Scripts can also be used to generate parts of the ontology programmatically at scale.

Yes, any tool that can create an ERD from a JDBC connection can also create an ERD from a Timbr ontology. This makes it easy to visualize and share your ontology model using familiar diagramming tools. For teams moving in the opposite direction, Timbr also supports importing ERDs into SQL ontologies as part of the modeling process.

Semantic SQL is standard SQL powered by explicit relationships defined in a SQL ontology, eliminating the need for complex JOIN and UNION statements. Queries are written against business concepts rather than raw tables, making them significantly shorter, easier to understand, and consistent across tools and teams.

By querying the SQL ontology using explicit relationships instead of raw tables, SQL queries are reduced in length and complexity by up to 90%. Relationships and business logic are defined once in the model, eliminating the need to reconstruct joins and filters in every query.

Timbr eliminates the need for JOINs by modeling relationships explicitly in the SQL ontology. Instead of reconstructing connections between tables in every query, relationships are defined once in the model and navigated directly, reducing query length by up to 90%. Users query business concepts rather than raw tables, and Timbr handles the traversal behind the scenes through virtual columns and graph-like path navigation.

Timbr’s caching engine uses a four-tier strategy that balances query speed and compute costs across different workload types. Tier 1 materializes data in the source database, Tier 2 caches in data lake storage, Tier 3 uses SSD for frequent access, and Tier 4 stores selected views in memory for real-time dashboards and high-frequency queries. Cached data is subject to the same role-based access, row-level security, and governance policies as live data.

Timbr’s data virtualization engine is an optimized version of Spark that scales up and out with an auto-scaler, and is used by customers across petabytes of data. The caching engine offers four tiers from normal to fastest:

1. Local Database – caches where the data lives, avoiding high-load compute time queries.
2. Data Lake – works across big data environments.
3. SSD – provides data locality and 10x faster performance than a data lake.
4. In-Memory – the fastest option, supporting near real-time performance with automated projections for optimized cache.

All tiers include a Job Scheduler that allows customers to materialize and cache in three clicks as CRON jobs, setting recurring refresh based on time intervals or triggers. All options also include partitioning and, when supported by the target source, indexes.

Timbr connects to business intelligence tools via JDBC, ODBC, and MDX, with plug-and-play compatibility that requires no custom development or new interfaces. In most BI tools the required drivers come pre-installed. SQL ontologies are accessible directly from BI dashboards, reporting tools, OLAP engines, Excel, and enterprise applications, allowing analysts to query business concepts and relationships without interacting with raw database structure.

Yes. Timbr connects to SpotFire via JDBC, the same way SpotFire connects to any data source.

Timbr connects to all popular data lakes, databases, BI tools, data science tools, and applications. Once connected, the SQL ontology can be queried using SQL, Python and R via DataFrames, natively in Apache Spark, or through the REST API. GraphQL is also supported through external open source projects that translate GraphQL to SQL.

Timbr integrates with every database, platform, and application using JDBC, ODBC, or REST API endpoints. When relevant, customers can also connect the Timbr MCP Server to other platforms’ MCP Servers.

Yes. Using the optimized Spark virtualization engine, when querying multiple databases, Timbr uses SparkSQL to join information across datasources.

Yes. Timbr integrates natively with Databricks, allowing you to create SQL ontologies directly on top of your Databricks environment. The semantic model is exposed in Unity Catalog and Hive metastore, and can be queried directly from Databricks notebooks using SQL, Python, R, or Scala. Timbr can also be configured as a datasource in Timbr via JDBC/ODBC. See the full Databricks integration documentation.

Yes. Timbr connects to Snowflake as a datasource via JDBC, allowing you to build SQL ontologies directly on top of your Snowflake data warehouse. Once connected, Timbr adds semantic graph capabilities to Snowflake – modeling business concepts, relationships, and metrics over your existing data without moving or duplicating it. See the full Snowflake integration documentation.

Yes. Microsoft Copilot Studio connects to Timbr via the Timbr MCP server, allowing Copilot agents to query your SQL ontology directly using natural language. Once connected, agents can execute semantic queries, retrieve governed business concepts and relationships, and generate SQL against your ontology within your existing Microsoft environment. See the Copilot Studio integration documentation for setup details.

Yes. Timbr’s REST API combines REST simplicity with GraphQL-like precision, exposing data through concept endpoints derived directly from the SQL ontology. Applications and AI agents can query business concepts like Customer, Order, or Product with nested relationship traversal in a single request, without referencing physical tables or writing JOINs. A self-documenting Swagger specification is auto-generated for every semantic model and stays current as the ontology evolves.

Yes. Timbr works extensively with SQLAlchemy, and DataFrames are also a valid option for Python users. See the Python consumption page for full details.

Yes. GraphQL is supported through external open source projects that translate GraphQL to SQL, allowing developers to query Timbr’s semantic model using GraphQL syntax. Alternatively, Timbr’s REST API offers similar flexibility with native support built in.

Yes. Timbr supports querying JSON and XML data using Apache Spark.

Yes. Timbr can generate SQL DDL statements directly from XML hierarchy and relationships, making the mapping straightforward.

Yes. Because Timbr uses standard SQL to query ontologies, SPARQL users can transition without learning a new language. The same semantic concepts and relationships they modeled in SPARQL are defined directly in Timbr’s SQL ontology, queryable using familiar SQL syntax.

Yes. Timbr integrates with data catalogs to automatically generate SQL ontologies mapped to your databases, turning metadata into a queryable knowledge graph. Timbr can also leverage the catalog’s business glossary and data mappings to enable discovery, governance, and lineage tracking across tools and AI agents.

Yes. Timbr transforms hybrid and multi-cloud architectures into a unified semantic layer that spans databases across Databricks, Snowflake, BigQuery, Synapse, AWS, Azure, Google Cloud, and on-premises systems. A single SQL ontology models relationships, metrics, and business rules across all environments, with data staying in place and no ETL or replication required. Deployment is via Kubernetes or Docker, with multi-cluster and on-premise options supported.

Yes. Timbr separates administrators from regular users through a role-based access control system. Administrators can create and manage ontologies, configure data sources, and assign user roles and permissions. Regular users access the semantic layer according to the permissions assigned to them, with no ability to modify the underlying model. Learn more about Timbr’s access control and role management.

A semantic data fabric connects diverse, distributed data sources through a virtual, unified semantic model mapped to federated data, without data movement or ETL processes. Timbr implements this by creating a SQL ontology across existing on-premise and cloud sources, modeling complex relationships and enabling consistent, governed data access for BI tools, analytics, and AI agents across the entire organization.

A semantic data fabric is a flexible, reusable layer that connects distributed data sources and provides universal meaning across the organization. It enables virtual integration of on-premise and cloud data without duplication or ETL pipelines, delivering consistent analytics and governance across systems. Timbr implements a semantic data fabric through its ontology-based semantic layer, connecting your existing infrastructure without requiring data movement.

A data mesh is a decentralized architecture where individual domain teams own and manage their data as a product, with shared governance standards across the organization. Unlike a data fabric, which builds a single virtual management layer over distributed data, a data mesh distributes ownership to the teams closest to the data. Timbr supports data mesh implementation through domain-oriented SQL ontologies that enable each team to model and expose their data products while maintaining enterprise-wide interoperability and governance.

A semantic data catalog is an intelligent inventory of data assets that defines shared meanings, hierarchies, and relationships across data silos, serving as a queryable knowledge encyclopedia for the organization. Timbr connects semantic data catalogs to your databases and BI tools, and can leverage existing catalog solutions such as Collibra or Informatica. Book a demo to see it in action.

A digital twin is a virtual model of a real-world system, asset, or process that mirrors live data to enable monitoring, simulation, and predictive analysis. Timbr powers AI-driven digital twins by representing machines, sensors, processes, and assets as relationally connected SQL ontologies, unifying operational and business data without ETL or duplication. The result is a governed, queryable semantic model that feeds BI tools, AI pipelines, and real-time dashboards from a single source.

Here are the FS patterns Timbr fits:

• Customer 360 / single customer view across core banking, cards, CRM, and external sources without consolidating them first.
• Credit risk and exposure – traversing customer, account, facility, collateral, and counterparty as ontology relationships instead of hand-coded joins.
• KYC / AML and fraud – connecting entities across siloed systems to surface networks and rings.
• Regulatory reporting – one governed definition of business terms so “exposure” or “default” means one thing, with lineage for the auditor.

Analysts and agents stop authoring brittle join algebra across a dozen banking systems and instead traverse a governed knowledge graph; Timbr compiles the traversal to optimized SQL.

For financial institutions that have invested in the Financial Industry Business Ontology, Timbr can also make FIBO-aligned concepts accessible and queryable through SQL rather than limiting their use to specialist semantic-web teams.

Yes. Timbr runs graph algorithms natively over SQL ontologies mapped to relational data, with no data export, ETL, or external graph database required. The default implementation uses Python NetworkX, with support for Nvidia CuGraph for GPU-accelerated performance. Supported algorithms include PageRank, community detection, fraud detection, similarity scoring, and more – all queryable directly from BI, ML, and AI tools using standard SQL.

Timbr is a virtual layer that does not store, move, or replicate data, so it inherits the HIPAA compliance posture of the underlying database. If your database is HIPAA compliant, Timbr operates within that same compliant environment. For specific compliance requirements, contact us to discuss your setup.

Timbr is a virtual layer that does not store, move, or replicate data, so it does not create new data residency or processing obligations under GDPR. Compliance depends on the configuration of the underlying database and how your organization manages data access and governance. For specific GDPR requirements, contact us to discuss your setup.