Executive summary
AtScale built a real category: a universal semantic layer that sits between cloud warehouses and BI tools, providing OLAP-style virtual cubes, hierarchies, aggregations, and aggregate-aware query rewriting. For enterprises with mature Tableau, Power BI, or Excel deployments who want consistent metric definitions and accelerated query performance against the warehouse, AtScale solves a real problem and solves it well.
Colrows solves a different problem. It is a semantic execution layer built for the AI-agent layer of the enterprise - autonomously building a typed semantic graph across the data estate, then compiling every agent intent into governed, deterministic, dialect-perfect SQL. Where AtScale models the data as cubes and accelerates BI consumption, Colrows models the data as a graph and compiles agent intent into governed SQL with policy injected at compile time.
In short:
- AtScale helps BI tools consume cube-shaped semantics fast.
- Colrows enables AI agents to compile graph-shaped intent into governed SQL.
For organisations whose AI ambitions extend beyond accelerated BI, the two architectures address different layers of the stack.
Two philosophies, two outcomes
AtScale assumes meaning is cube-shaped and consumed by BI tools. Modellers define virtual cubes, hierarchies, calculated measures, and dimensional relationships. AtScale's query engine receives MDX, DAX, or SQL from BI tools, rewrites queries to hit pre-computed aggregates where possible, and returns results. The semantic layer is rich within the OLAP vocabulary - measures, hierarchies, calculated members, role-playing dimensions - and its primary value is performance and consistency for the BI ecosystem.
Colrows assumes meaning is graph-shaped and consumed by autonomous agents. Definitions live in catalogues, BI tools (including AtScale), dbt models, runbooks, Confluence, and historical query usage. Colrows ingests these sources and constructs a typed semantic graph autonomously. The graph is multi-scope (global, datastore, persona, user) and uses multi-vector embeddings (definition, usage, combined per concept). The consumer is an AI agent generating intent in natural language that needs deterministic compilation with policy injected at compile time.
The downstream consequence: AtScale optimises BI-tool experience against a manually-modelled cube. Colrows optimises agent-execution correctness against an autonomously-maintained graph.
OLAP cube vs. semantic graph
The most important architectural distinction is the data model the layer assumes.
AtScale models the data as cubes. Dimensions, hierarchies, measures, aggregate tables. The mental model is multi-dimensional analysis: revenue by product by region by quarter. The query engine is built to slice, dice, and accelerate that pattern.
Colrows models the data as a typed graph. Concepts (Customer, Order, Subscription), typed edges between them (Customer has Order, Order belongs to Subscription), governance predicates attached at every node and edge, multi-scope resolution per persona and tenant, and proven join paths an AI agent traverses to answer multi-hop questions.
Many BI questions fit a cube model. Many AI agent questions do not - they require traversal across entities, relationships, and governance scopes that a cube cannot represent without flattening.
A concrete scenario: pharmaceutical compliance investigation
A global pharmaceutical company runs AtScale to power its sales-performance dashboards. Tableau and Excel users get fast, consistent answers to questions like quarterly product sales by region by therapeutic area. The cube is well-modelled, the aggregate-aware query rewriting reduces warehouse cost, and the BI team is rightly proud of the work.
Now the compliance team wants an AI agent that can investigate: "For the last three quarters, identify any field-force interactions in Region X that exceeded our promotional-spend policy thresholds for that therapeutic area, cross-checked against the prescribing physician's specialty and current speaker programme participation, and explain why each flagged interaction is or is not a compliance issue."
This is not a cube question. The agent must reason across:
- FieldRep, PhysicianContact, PromotionalSpend, SpeakerProgramme, TherapeuticArea, and ComplianceRule entities and the typed relationships between them.
- The compliance officer persona's permission to see specific PII columns, but only when scoped to active enforcement files.
- Predicates that vary per region, therapeutic area, and time period (because internal policies and external regulations both change).
- An audit trail proving exactly which definitions and policies were in force when the agent reached its conclusion.
AtScale can deliver fast cube slices for the underlying spend data. But the agent reasoning is graph traversal, the governance is multi-scope and time-variant, and the audit must be defensible. None of that lives in the cube.
With Colrows, the agent compiles its intent through a typed semantic graph that already encodes those entities, relationships, and policies. Compile-time governance injects the right predicates per persona, per scope, per date. The audit trail is point-in-time reproducible. New policies ingested as documentation update the graph without an OLAP modelling deploy.
Why OLAP semantic layers cannot do this
AtScale is excellent at one thing: accelerated, governed BI consumption from a multi-dimensional model. It is not designed to:
- Model entity-and-relationship graphs for multi-hop agent reasoning.
- Compile free-text agent intent deterministically into governed SQL.
- Inject row/column-level predicates at compile time across persona, tenant, and regulatory scope.
- Build or maintain itself from documentation, runbooks, and usage signals.
- Produce machine-readable compile traces for AI audit.
Each of those is foundational for putting AI agents into production. Adding them on top of AtScale is not a configuration change - it is a different architecture layered above OLAP.
Reframing the comparison
AtScale and Colrows operate on different data models and serve different consumers.
AtScale = universal semantic layer, OLAP-shaped, BI-tool-facing. Optimised for accelerated, consistent multi-dimensional analytics. Modelling is manual. Resolution happens inside AtScale's query engine, often hitting pre-computed aggregates.
Colrows = semantic execution layer, graph-shaped, agent-facing. Optimised for governed, deterministic compilation of AI agent intent. The graph is built and maintained autonomously. Resolution happens at compile time, with policy injected before any SQL touches the warehouse.
The two coexist cleanly: keep AtScale powering your BI ecosystem; add Colrows as the agent-execution surface that compiles intent into governed SQL.
The bottom line
If your goal is accelerated, governed BI consumption from Tableau, Power BI, or Excel - and your team has invested in a multi-dimensional cube model - AtScale is a capable choice and a sensible default for OLAP-style analytics.
If your goal is to put AI agents into production - to compile their intent into governed SQL with proven joins, compile-time policy enforcement, and a continuously maintained semantic graph that evolves with your business - the data model AtScale assumes is too narrow. The semantic execution layer above it is what matters, and that is what Colrows provides.
At the core
| AtScale | Colrows | |
|---|---|---|
| Built for | BI consumption from cubes | Semantic execution for AI agents |
| Primary consumer | Tableau, Power BI, Excel, BI users | AI agents, autonomous workflows |
| Core strength | Aggregate awareness and BI-tool integration | Governed compilation of agent intent |
| Intelligence lives in | OLAP cube definitions | Typed semantic graph |
Semantic and intelligence handling
| Capability | AtScale | Colrows |
|---|---|---|
| Data model | Multi-dimensional cube | Typed semantic graph |
| Authoring model | Manual modelling and aggregate design | Autonomous, continuously maintained |
| Multi-hop reasoning | Limited - cube traversal only | Native - graph traversal across entities |
| Multi-scope resolution | Role-based dimensions | Global, datastore, persona, user scopes |
| AI readiness | Indirect - via SQL/MDX/DAX endpoints | Agent-native by design |
| Explainability | Query rewrite trace | End-to-end (intent → semantics → SQL → source data) |
Engineering and operational reality
| Dimension | AtScale | Colrows |
|---|---|---|
| Compile-time governance | Partial - role-based row filters | Yes - RBAC/ABAC injected into generated SQL |
| Aggregate awareness | Yes - core feature | Compile-level, dialect-perfect SQL with optimised joins |
| Drift handling | Manual cube redesign | Autonomous detection plus proposed mappings |
| Data replication | Sometimes required for aggregate tables | None - compiles SQL that runs on the warehouse |
| Audit trail | Query history | Point-in-time reproducible compilation trace |
| Coexistence | - | Ingests AtScale cube definitions; AtScale continues for BI |
Frequently asked questions
Is Colrows a replacement for AtScale?
For BI-tool consumption (Tableau, Power BI, Excel) of OLAP-shaped semantics, AtScale is purpose-built. Colrows replaces AtScale only when the consumer is AI agents instead of BI tools - then the agent-native compile pipeline, autonomous graph, and compile-time governance matter more than OLAP query acceleration.
Can Colrows ingest AtScale virtual cubes?
Yes. Cube definitions, dimensions, hierarchies, and aggregations modelled in AtScale can seed the Colrows semantic graph as a starting point. Colrows then maintains the graph autonomously and exposes it to AI agents via an agent-native compile surface that AtScale was not designed to provide.
Why is OLAP-shaped semantics not enough for AI agents?
AI agents reason across entities and relationships, not multi-dimensional cubes. A cube is optimised for slice-and-dice questions: revenue by region by quarter. An agent investigating a fraud spike has to traverse Customer to Transaction to Merchant to RiskEvent to ComplianceScope - that is graph traversal, not cube slicing. The data model itself is different.
How does aggregate awareness compare to compile-time governance?
AtScale's aggregate awareness rewrites queries to hit pre-computed aggregates for performance. That solves a query-acceleration problem. Compile-time governance solves a different problem: injecting RBAC, ABAC, and row/column-level predicates into the generated SQL before any byte is fetched. Both are valid - they address different pain points.
Is Colrows positioned as a BI semantic layer like AtScale?
No. AtScale targets the BI-tool ecosystem - Tableau, Power BI, Excel, and similar. Colrows targets AI agents and autonomous workflows. The architectures, the consumer assumptions, and the runtime patterns are different.
Can I run AtScale and Colrows together?
Yes. They serve different consumer audiences. AtScale powers your BI-tool experience; Colrows powers your AI agents. They share the underlying warehouse and can both compile to dialect-perfect SQL against it.
Further reading
- What is a semantic layer? (Pillar guide) - the definitive 2,000-word guide to the category.
- Colrows vs Cube.js - hand-authored metric API vs. semantic execution layer.
- Colrows vs dbt Semantic Layer - metric layer above transformations vs. semantic graph above the warehouse.
- Colrows vs Looker - presentation-time BI semantic layer vs. compile-time agent execution layer.
- Snowflake, Databricks & the Semantic Layer - how warehouse-native and platform-native semantic layers compare.