timbr core
SQL Metric Store
Timbr’s SQL Metric Store lets teams define and govern reusable business metrics in standard SQL, ensuring consistency across BI, data platforms, and AI. It delivers governed, semantic, AI-ready measures for analytics, dashboards, and agents.
Auto-Discovery and Intelligent Suggestions
Timbr accelerates metric creation through semantic context awareness, reducing manual effort and ensuring alignment with domain logic:
- Analyzes relationships and data usage patterns to suggest relevant measures.
- Recommends aggregations, filters, or calculated fields during model authoring.
- Flags redundant or duplicate measures for standardization.
SQL-Native and Universally Accessible
Timbr metrics are accessible in standard SQL and are automatically compiled into SQL expressions and pushed down to the data source in its native dialect (e.g., Databricks SQL, Snowflake SQL), avoiding vendor lock-in.
- BI tools: Power BI, Tableau, Looker, Excel, SAP BO (via JDBC, ODBC, MDX)
- Notebooks & data science environments: Python (SQLAlchemy), R, Scala, Java
- AI workflows and Apps: Timbr’s LangChain & GraphRAG SDKs, plus LLMs integrated via REST APIs
Benefits at a Glance
Timbr’s SQL Metric Store enables users to define reusable, governed measures, including metrics, KPIs, and complex calculations, directly in the semantic model using standard SQL. It drives consistency, transparency, and agility in metric management, empowering data teams to move faster with trusted definitions.
Define metrics once, use them anywhere with confidence
Faster by design: SQL metrics pushed Down to execute at source
Enable metric discovery and reuse across semantic domains
Govern and audit metric changes with full lineage and role-based control
Speed up Power BI migration with automated DAX-to-SQL conversion
Support AI, analytics, and data apps with trusted, SQL-native metrics
Define Metrics as First-Class Semantic Objects
In Timbr, measures are modeled alongside concepts and relationships in the ontology, turning KPIs into reusable semantic assets across all consumption workflows. Users define metrics using simple SQL expressions, including:
Simple
aggregations
(e.g., SUM(sales_amount), AVG(session_duration))
Complex business logic
with filters, CASE statements, and calculations
Custom-calculated properties
embedded in ontology concepts or virtual views
All measures are stored, versioned, and governed alongside the data model, ensuring a single source of truth for calculations across teams and tools.
Faster by Design:
SQL-Native Execution
Unlike metrics defined in proprietary engines (such as DAX or custom semantic runtimes), Timbr’s SQL measures are executed directly by your underlying data platform, compiled into standard SQL and pushed down to engines like Databricks, Snowflake, BigQuery, or Synapse. This means there’s no translation layer, no runtime bottleneck, and no performance tradeoff:
- Full query pushdown to the source engine’s optimizer.
- Integration with native performance features like materialized views, indexes, and distributed execution.
- Federated JOINs and Aggregations with Timbr Virtualization.
- Smart pushdowns to execute only what’s needed across systems.
- Consistent behavior across tools, with no surprises in query logic or results.
- Scalable performance that grows with your cloud or on-prem infrastructure.
This architecture ensures Timbr delivers not only governance and reuse, but also enterprise-grade speed for all metrics, without locking you into a proprietary format.
Inheritable, Reusable and Governed
The SQL Metric Store empowers enterprise-grade governance:
- Centralized metric definitions eliminate inconsistencies across tools and departments.
- Metric inheritance allows new measures to extend existing logic (e.g., profit margin variants by region).
- Cross-domain reuse of standardized KPIs enables semantic consistency across business units.
- Role-based access controls determine who can view or edit metrics.
These capabilities turn metrics into shareable, governed knowledge assets, not just SQL snippets.
