business intelligence
Looker
Timbr elevates Looker by replacing repetitive LookML with a centralized semantic layer in SQL.
Business users gain easier access to governed data, while auto-aggregations, native support for cubes and hierarchies, caching, and data source virtualization accelerate performance and reduce complexity, enabling faster insights across tools without compromising control or consistency.
Key Capabilities
Eliminate LookML duplication
Reduce complexity in LookML by sourcing pre-defined metrics, cubes and hierarchies.
Consistent Metric
Definitions
Centralize business definitions and hierarchies and reuse across BI tools.
Controlled
Access
Enforce row-level and role-based access controls directly within the semantic layer.
Access
Big Data
Query big data with confidence, Timbr pushes compute to the data sources.
Access Virtualized
Data
Avoid workbook bloat and crashes with virtualized, on-demand queries.
Accelerate
Dashboards
Benefit from semantic caching and auto-aggregations for fast, repeated queries
Timbr vs. LookML:
Complement or Replacement?
While LookML is Looker’s native modeling language, it has limitations when used in isolation, especially across complex data ecosystems. Timbr addresses these by offering a governed, SQL-native semantic layer that can either replace or coexist with LookML, depending on your strategy.
| Feature / Need | LookML | Timbr |
|---|---|---|
| Modeling Language | LookML (YAML-based DSL) | Standard SQL or visual UI |
| Reusability across tools | No, locked to Looker | Define once, reuse anywhere |
| OLAP modeling | Not natively supported | Ontology driven cubes and hierarchies |
| Caching & auto-aggregations | Limited or requires manual modeling | 4-tier cache with usage-based auto-aggregates |
| Data source virtualization | One source per connection block | Federate across databases via a unified model |
| Security (RLS, CLS) | LookML-defined filters | Native RBAC + row/column-level security |
- Unified Modeling: You want to model your logic once in SQL and use it across tools.
- Enhanced Governance: You need better governance, caching, and cross-source modeling.
- Avoid Lock-in: You’re migrating away from Looker or reducing platform lock-in.
- Gradual Adoption: You want to gradually adopt Timbr while retaining some LookML models.
- Hybrid Use: You want Looker to consume a governed semantic layer but still define views locally for specific use cases.
OLAP Capabilities
Looker supports OLAP-style analysis: slicing, drilling, and aggregating data across dimensions, but lacks traditional cube infrastructure. Timbr fills this gap by modeling cubes, hierarchies, and reusable measures in a centralized, SQL-native layer. This brings true OLAP structure to Looker, enabling consistent, high-performance multidimensional analysis, without the rigidity of legacy cube engines.
Here’s how Timbr offers OLAP-like functionality:
- Define cubes, dimensions, and measures using standard SQL.
- Create semantic hierarchies for drill-down and roll-up operations.
- Use semantic auto-aggregations and a four-tier caching engine to serve queries from pre-aggregated projections.
- Support MDX endpoints for Excel and legacy pivoting tools.
- Push compute and aggregations down to your data warehouse for real-time performance.
While Timbr does not deliver “traditional” OLAP cubes, it achieves the same goals, governed, multidimensional analysis at scale, through virtual models and semantic intelligence. That’s why we describe Timbr as “OLAP-like”: it’s OLAP, reimagined for the cloud and SQL-first data stacks.
How it Works
Timbr connects to Looker through a standard JDBC connection. Instead of building complex LookML models per dataset, teams query a unified semantic layer where entities, relationships, and measures are already defined. Timbr rewrites queries into optimized SQL pushed down to the data platform or served from a semantic cache. The result: Looker users enjoy consistent metrics and faster dashboards, without duplicating logic in every explore or view.
