The rise of AI in analytics has changed how organizations interact with data. Instead of manually building dashboards and SQL queries, teams now want AI agents that can answer questions, generate insights, and explore data automatically.
But there’s a major problem:
· AI is only as reliable as the data foundation beneath it.
· If the data definitions are inconsistent, metrics are duplicated, or business logic is scattered across dashboards and SQL scripts, AI-generated insights quickly become inaccurate and untrustworthy.
This is where Cube takes a very different approach.
1. The Problem with Traditional BI and AI Analytics
In many organizations today:
· Every dashboard tool defines metrics differently
· Teams write their own SQL queries
· Business logic is duplicated everywhere
· Security rules are implemented inconsistently
· AI tools directly access raw warehouse tables
This creates chaos.
For example:
· One dashboard says revenue is ₹10M
· Another says ₹12M
AI agents generate different answers depending on which tables they query. Users stop trusting the data
The root cause is simple; there is no centralized semantic understanding of the business.
2. What Is a Semantic Layer?
A semantic layer acts as a translation layer between raw warehouse data and business users.
Instead of exposing raw database tables like:
· orders
· customers
· payments
· transactions
the semantic layer exposes business concepts like:
· Total Revenue
· Active Customers
· Conversion Rate
· Monthly Orders
This means everyone dashboards, analysts, APIs, and AI agents uses the exact same definitions.
Think of it like this:
|
Raw Database |
Semantic Layer |
|
Technical tables |
Business-friendly metrics |
|
Complex joins |
Reusable models |
|
SQL knowledge required |
Business concepts |
|
Different logic everywhere |
Centralized definitions |
The semantic layer becomes the single source of truth for the organization.
3. What Makes Cube Different?
Many BI tools support semantic models in some form. But Cube was designed differently from the ground up.
At the center of Cube’s architecture is an open-source semantic layer specifically built for modern analytics and AI-powered applications. Unlike traditional BI tools, Cube separates:
· Data modeling
· Governance
· Query execution
· AI interaction
This separation is what enables agentic analytics.
4. What Is Agentic Analytics?
Agentic analytics means AI agents can:
· Explore data
· Ask follow-up questions
· Generate insights
· Build calculations dynamically
· Reason about business metrics
without humans manually writing every query. But for this to work safely, AI needs guardrails.
Without guardrails, AI may:
· Generate invalid SQL
· Use incorrect joins
· Access restricted data
· Miscalculate business metrics
· Create inconsistent reports
Cube solves this problem using its semantic layer runtime.
5. Cube’s Trusted Proxy Architecture
One of Cube’s most important design decisions is this, AI agents never directly query the data warehouse. Instead, they communicate with Cube’s semantic layer. The semantic layer acts as a trusted proxy between AI and the warehouse.
Architecture flow:
AI Agent ↓ Cube Semantic Layer ↓ Cloud Data Warehouse
This is extremely important.
Why?
Because every query must pass through Cube’s deterministic runtime before reaching the warehouse.
That runtime:
· Validates queries
· Applies governance rules
· Enforces security policies
· Prevents invalid access
· Ensures metric consistency
This creates a safe environment for AI-driven analytics.
6. Why Direct Warehouse Access Is Dangerous for AI
Imagine giving an AI agent direct access to your warehouse.
The AI might:
· Join incorrect tables
· Use deprecated columns
· Misinterpret business definitions
· Accidentally expose sensitive data
· Generate extremely expensive queries
Even worse, different AI prompts may generate different SQL for the same metric.
Prompt 1: What is total revenue this month?
AI generates: SUM(order_amount)
Prompt 2: What are completed sales?
AI generates: SUM(CASE WHEN status='completed' THEN amount END)
Now your organization has two different revenue numbers. This destroys trust. Cube prevents this by centralizing metric definitions in the semantic layer.
7. Introducing Semantic SQL
Cube introduces something called Semantic SQL. This is one of the most innovative parts of the platform.
Instead of inventing a completely new query language, Cube extends standard PostgreSQL-compatible SQL. This means developers and AI systems can still use familiar SQL syntax.
But Cube adds semantic capabilities on top.
7.1 Understanding Semantic SQL in Cube
To understand Semantic SQL, let us walk through a complete example using:
· a PostgreSQL table,
· sample data,
· a Cube semantic model,
· a semantic query specification,
· and the final SQL generated by Cube.
This will help you clearly understand how Cube separates:
· business semantics,
· query intent,
· and physical SQL generation.
Step 1: Create the Orders Table in PostgreSQL
Imagine we have a simple ecommerce orders table.
PostgreSQL DDL
CREATE TABLE orders ( order_id BIGSERIAL PRIMARY KEY, customer_id BIGINT NOT NULL, order_total NUMERIC(10,2) NOT NULL, order_date TIMESTAMP NOT NULL, delivery_status VARCHAR(50) NOT NULL, payment_method VARCHAR(50), store_id BIGINT, delivery_partner_id BIGINT );
Step 2: Insert Sample Data
PostgreSQL DML
INSERT INTO orders ( customer_id, order_total, order_date, delivery_status, payment_method, store_id, delivery_partner_id ) VALUES (101, 2500.50, '2026-05-01 10:15:00', 'On Time', 'UPI', 1, 9001), (102, 1800.00, '2026-05-01 11:20:00', 'Late', 'Credit Card', 1, 9002), (103, 3200.75, '2026-05-02 09:45:00', 'On Time', 'Cash', 2, 9003), (104, 4500.00, '2026-05-02 14:10:00', 'Late', 'UPI', 2, 9001), (105, 1500.25, '2026-05-03 16:30:00', 'On Time', 'Debit Card', 3, 9002);
app_db=# SELECT * FROM orders; order_id | customer_id | order_total | order_date | delivery_status | payment_method | store_id | delivery_partner_id ----------+-------------+-------------+---------------------+-----------------+----------------+----------+--------------------- 1 | 101 | 2500.50 | 2026-05-01 10:15:00 | On Time | UPI | 1 | 9001 2 | 102 | 1800.00 | 2026-05-01 11:20:00 | Late | Credit Card | 1 | 9002 3 | 103 | 3200.75 | 2026-05-02 09:45:00 | On Time | Cash | 2 | 9003 4 | 104 | 4500.00 | 2026-05-02 14:10:00 | Late | UPI | 2 | 9001 5 | 105 | 1500.25 | 2026-05-03 16:30:00 | On Time | Debit Card | 3 | 9002 (5 rows)
At this stage, the database only knows:
· tables,
· columns,
· rows,
· and raw data.
The database does not understand business concepts like:
· Total Revenue
· Total Orders
· On-time Deliveries
Those concepts are defined in the semantic layer.
Step 3: Define the Semantic Model in Cube
Now we create a Cube semantic model.
This is where business logic becomes centralized and reusable.
Cube YAML Semantic Model
cubes: - name: Orders sql_table: orders measures: - name: totalRevenue sql: order_total type: sum title: Total Revenue - name: totalOrders type: count title: Total Orders - name: avgOrderValue sql: order_total type: avg title: Average Order Value - name: onTimeDeliveries type: count title: On-time Deliveries filters: - sql: "{CUBE}.delivery_status = 'On Time'" - name: lateDeliveries type: count title: Late Deliveries filters: - sql: "{CUBE}.delivery_status = 'Late'" dimensions: - name: orderId sql: order_id type: number primary_key: true - name: customerId sql: customer_id type: number - name: orderDate sql: order_date type: time - name: deliveryStatus sql: delivery_status type: string - name: paymentMethod sql: payment_method type: string
The semantic layer now defines:
· how revenue is calculated,
· how orders are counted,
· what qualifies as a late delivery,
· and which business metrics are officially approved.
Instead of every dashboard or AI agent writing SQL independently, everyone now uses these centralized semantic definitions.
This is the foundation of Semantic SQL.
Step 4: Query Using Semantic Concepts
Now let us imagine a dashboard or AI agent wants:
· total revenue,
· total orders,
· and on-time deliveries.
Instead of writing raw SQL, it sends a semantic query specification.
{
"measures": [
"Orders.totalRevenue",
"Orders.totalOrders",
"Orders.onTimeDeliveries"
],
"dimensions": [],
"filters": []
}
Notice something very important.
The query does not contain:
· SUM()
· COUNT()
· CASE WHEN
· table joins
· or filtering logic.
It only references semantic business metrics. This is why it is called Semantic SQL.
The query expresses "What business information do I want?" rather than "How should SQL calculate it?"
Step 5: Cube Generates the Actual SQL
Cube’s semantic layer runtime interprets the semantic query and generates optimized PostgreSQL SQL automatically.
Generated SQL
SELECT sum("orders".order_total) "orders__total_revenue", count("orders".order_id) "orders__total_orders", count(CASE WHEN ("orders".delivery_status = 'On Time') THEN "orders".order_id END) "orders__on_time_deliveries" FROM orders AS "orders"
This SQL is what finally gets executed in PostgreSQL.
app_db=# SELECT sum("orders".order_total) "orders__total_revenue", count("orders".order_id) "orders__total_orders", count(CASE WHEN ("orders".delivery_status = 'On Time') THEN "orders".order_id END) "orders__on_time_deliveries" FROM orders AS "orders"; orders__total_revenue | orders__total_orders | orders__on_time_deliveries -----------------------+----------------------+---------------------------- 13501.50 | 5 | 3 (1 row)
Why This Is Powerful?
Without a semantic layer:
· every dashboard writes its own SQL,
· business logic gets duplicated,
· AI generates inconsistent queries,
· and metrics drift across teams
Traditional SQL vs Semantic SQL
|
Traditional SQL |
Semantic SQL |
|
Business logic inside every query |
Business logic centralized in semantic models |
|
Developers write aggregations manually |
Queries reference semantic metrics |
|
High risk of inconsistent metrics |
Trusted reusable definitions |
|
AI generates raw SQL |
AI uses governed semantic concepts |
|
Queries tightly coupled to database schema |
Queries operate at business abstraction level |
Why Semantic SQL Matters for AI
AI systems are very good at generating SQL syntax. But AI does not naturally understand:
· organizational business definitions,
· approved metrics,
· governance policies,
· or trusted joins.
Semantic SQL gives AI a controlled abstraction layer. Instead of inventing revenue calculations dynamically, AI simply requests:
Orders.totalRevenue
The semantic layer already knows:
· how revenue should be calculated,
· which filters apply,
· and what governance rules exist.
This makes AI-powered analytics:
· safer,
· more reliable,
· and more consistent.
Semantic SQL is not about replacing SQL. It is about moving from raw database querying to governed business-aware querying.
In Cube:
· Raw data lives in databases like PostgreSQL
· Business semantics live in Cube models
· Queries reference semantic metrics
· Cube generates optimized SQL automatically
This architecture is becoming increasingly important for modern analytics platforms and AI-powered data systems because it creates:
· consistency,
· governance,
· trust,
· and reusable business intelligence.
7.2 Open Source Advantage
Another important difference is that Cube’s semantic layer is open source. This gives organizations:
· Transparency
· Extensibility
· Vendor flexibility
· Community innovation
· Better control over analytics infrastructure
Instead of locking semantic logic inside proprietary BI tools, Cube allows teams to define semantics as code.
In summary, Cube is not just another BI tool. Its core innovation is the combination of:
· An open semantic layer
· Deterministic governance
· Semantic SQL
· AI-safe query execution
· Trusted proxy architecture
This architecture enables organizations to move toward agentic analytics while maintaining trust, consistency, and security.
As AI becomes more deeply integrated into analytics workflows, semantic layers like Cube’s will likely become a standard part of modern data infrastructure.
Because in the age of AI analytics, trusted semantics matter more than raw SQL access
Previous Next Home
No comments:
Post a Comment