DEV Community: XLTable

Excel Is Still the #1 Self-Service Analytics Tool. Here's Why That's Not a Problem Anymore.

XLTable — Tue, 09 Jun 2026 14:12:52 +0000

Excel Is Still the #1 Self-Service Analytics Tool. Here's Why That's Not a Problem Anymore.

Your company just renewed its Tableau license. Your analysts just exported the data to Excel.

This scene plays out in nearly every enterprise analytics department in the world. And yet, IT leaders keep funding BI platforms, training programs, and data governance initiatives — while business users quietly keep opening spreadsheets.

This isn't a failure. It's a signal. And understanding what it means is the key to building an analytics stack that people actually use.

What Self-Service Analytics Actually Means

Self-service analytics refers to the ability of business users — not data engineers or BI developers — to independently access, explore, and analyze data without submitting a ticket to IT.

The market has taken notice. Analysts estimate the global self-service analytics market was valued at roughly $5–6 billion in 2024, growing at a CAGR of ~16% toward a potential $17–27 billion by the early 2030s. The growth is real. But it masks a more nuanced picture on the ground.

For CTOs and IT directors, the promise of self-service is compelling: fewer bottlenecks, faster decisions, reduced dependency on data teams. The challenge is delivering on that promise without creating a mess of shadow reports and disconnected data sources.

The Landscape: A Quick Map of the Tools

There are five broad categories of tools that compete — and coexist — in the self-service space:

Spreadsheets (Excel, Google Sheets) — The original self-service layer. Every business user already knows them.
Modern BI platforms (Power BI, Tableau, Looker) — Visualization-first tools with strong governance features and growing AI capabilities.
Embedded analytics (Metabase, Redash) — Lightweight, often open-source, embedded inside applications.
Headless BI / semantic layer (dbt Metrics, Cube.dev) — Code-first approaches to defining business logic independently of visualization.
OLAP servers (Microsoft Analysis Services, XLTable) — Traditional and modern cube-based engines that sit between databases and analytics clients.

Each category has genuine strengths. The problem is that organizations often treat them as competitors when they are more naturally complements.

The Excel Paradox

Let's be direct: Excel is not going away. Over 200 million enterprise users are licensed on Microsoft 365 globally. More than 1.3 million companies in the US alone use it. It is the most widely declared skill on LinkedIn among corporate professionals, ranging from 17% to 32% penetration depending on job function.

And yet, the standard narrative in enterprise IT is that Excel is a legacy tool — a crutch for users who haven't been properly trained on "real" analytics platforms.

This framing is wrong, and it's causing expensive mistakes.

Executives don't use Tableau to build their Monday morning model. They use Excel. That's not a training problem. That's a product-market fit signal.

Excel's persistence isn't about inertia. It's about control. A pivot table in Excel is something a finance director can manipulate in real time, in a meeting, with no dependency on a dashboard developer. The cognitive overhead is near zero. The flexibility is near infinite.

The actual problem with Excel isn't Excel. It's the data feeding it.

The Real Bottleneck: Data Access, Not the Spreadsheet

When analysts export from Snowflake or ClickHouse into a CSV and then import it into Excel, two things go wrong:

The data is stale the moment it lands in the file.
The analyst becomes a manual ETL pipeline — a job they weren't hired to do.

This is where the architecture conversation needs to shift. The question isn't "How do we get users off Excel?" It's "How do we give Excel a live, governed connection to real data?"

The answer exists and has for decades — it's called XMLA. It's the protocol that Microsoft built for exactly this scenario: connecting Excel PivotTables to analytical databases through a standardized interface. Analysis Services used it. Power BI uses it. And modern OLAP servers can expose it to any backend — ClickHouse, Snowflake, BigQuery, StarRocks, Databricks.

When you connect Excel to a properly modeled OLAP cube, several things change simultaneously:

Users get live data, not exports.
Business logic (metrics, hierarchies, access rules) lives in one place — the semantic layer.
Finance stays in Excel. IT controls the data.
No SQL required for end users. No BI license required per seat.

What CTOs Should Actually Be Asking

Most analytics infrastructure reviews focus on the wrong question: "Which BI tool should we standardize on?" A better set of questions:

Where does data actually get consumed? Follow the spreadsheets, not the dashboards.
What is the total cost of the export-import loop? Count analyst hours, not just license fees.
Do we have a semantic layer? If business logic lives in reports rather than in a governed model, you have a governance problem regardless of which tool you use.
Can our stack serve both technical and non-technical users from the same source of truth? If the answer is "no," you are maintaining two parallel data cultures.
What is the adoption rate of our BI investments? If it's below 30%, the tool is not the answer.

A modern analytics stack doesn't have to choose between Excel and BI. It can serve both — provided the data layer is properly architected.

The Modern Answer: Embrace Excel, Fix the Data Layer

Here is a practical architecture that resolves the Excel paradox without forcing users to abandon tools they trust:

Build a semantic layer on top of your analytical database. Define measures, dimensions, hierarchies, and access rules once.
Expose that layer via XMLA so Excel connects natively — no plugins, no extensions.
Keep BI tools for dashboards, alerts, and shared views. They're excellent at that.
Let Excel do what Excel does: ad-hoc analysis, financial modeling, executive reporting.

The result is a stack where data governance and user freedom aren't in tension. IT owns the model. Business owns the analysis.

What About AI Chat? ChatGPT, Claude, and the "Just Ask" Trend

There's a growing narrative that AI chat interfaces will replace both Excel and BI tools entirely. Users are already asking ChatGPT for dashboards and getting back static charts. The question CTOs are asking: is this the end of structured analytics?

The honest answer is: AI chat and Excel are not competing for the same job.

AI chat interfaces excel at one thing — answering a one-off question quickly. "What was our best-performing region last quarter?" works well in a chat window. But the moment you need that answer to be repeatable, auditable, consistent across departments, and connected to data that updates daily — chat alone falls short.

Here's why:

Data is not live. Users upload a CSV from yesterday. Tomorrow they upload a new one. The export-import loop moves from email to chat — but it's still a loop.
No single source of truth. Every employee gets their own answer from their own data. Finance and Sales produce different numbers for the same metric.
No audit trail. A CFO cannot sign off on a report generated by a language model without traceability.
Security. Most enterprise data governance policies prohibit sending sensitive business data to external AI providers.

AI chat is an interface for one-off questions. Excel and BI are the environment for repeatable, governed, auditable decisions. They are not competitors — they are built for different jobs.

But here is where the picture gets more interesting — and where the real opportunity lies.

When an AI assistant connects directly to a live semantic layer via a protocol like MCP (Model Context Protocol), the equation changes entirely. Instead of answering from a stale uploaded file, an AI can query a live OLAP cube and return current, governed data — directly in the chat interface.

This means the user gets the conversational experience they want, with the data integrity the organization requires. The AI becomes a natural language interface to the same semantic layer that powers Excel PivotTables and BI dashboards — not a replacement for it.

For organizations building on a modern OLAP layer, this is not a threat. It is an additional channel — one that makes the investment in a proper semantic layer even more valuable.

Conclusion

Self-service analytics is not a tool. It's a capability. And the most effective organizations build it around how their people actually work — not around how vendors think they should work.

Excel is not the enemy of modern analytics. Ungoverned data is. Once you solve the data layer, the spreadsheet becomes a feature.

Stop trying to replace Excel. Start connecting it to something worth analyzing.

XLTable + Snowflake: From Zero to Pivot Table in 15 Minutes

XLTable — Sat, 04 Apr 2026 18:49:00 +0000

XLTable + Snowflake: From Zero to Pivot Table in 15 Minutes

This guide shows how to connect Excel to Snowflake using XLTable — from creating sample tables to dragging measures into a Pivot Table.

No custom data required. Everything runs on a free Snowflake trial account.

What You Will Build

By the end of this guide you will have:

A Snowflake database with realistic sales and inventory data
An OLAP cube named myOLAPcube registered in XLTable
A live Excel Pivot Table connected to Snowflake — no CSV exports, no BI tools

Data Model Overview

The sample script creates 8 tables in the olap.public schema:

Table	Rows	Description
`Times`	731	Calendar: every day of 2023–2024
`Regions`	4	Sales regions: North, South, East, West
`Managers`	5	Sales managers linked to regions (many-to-many)
`Stores`	8	Retail stores, each assigned to a region
`Models`	8	Product models (Alpha … Theta)
`Sales`	3 000	Transactions: store, model, date, quantity, amount
`Stock`	500	Inventory snapshots: store, model, quantity on hand
`olap_definition`	1	OLAP cube definition read by XLTable

The relationships are straightforward: Sales and Stock facts join to Stores, Models, and the Times calendar. Stores belong to Regions, and Managers are linked to Regions in a many-to-many relationship.

Prerequisites

Before starting, make sure you have:

A Snowflake account (Trial or paid)
A user with SYSADMIN role or CREATE DATABASE privilege
A running virtual warehouse (e.g. COMPUTE_WH)
SnowSQL CLI installed, or access to Snowflake Worksheets
XLTable server installed and running

Step 1: Run the SQL Script

Download the script and run it against your Snowflake account:

👉 Download snowflake_sample.sql

Option A — SnowSQL CLI

snowsql \
  --accountname <your_account> \
  --username    <user> \
  --dbname      olap \
  --schemaname  public \
  -f snowflake_sample.sql

Option B — Snowflake Worksheets

Open Snowflake → Worksheets → + New Worksheet
Paste the full script
Select your warehouse
Click Run All

Verify the result:

SELECT table_name, row_count
FROM olap.information_schema.tables
WHERE table_schema = 'PUBLIC'
ORDER BY table_name;

You should see 8 tables with the row counts from the table above.

Step 2: Configure XLTable

Open /usr/olap/xltable/setting/settings.json and add the Snowflake connection:

{
    "SERVER_DB": "Snowflake",
    "CREDENTIAL_DB": {
        "user":      "<user>",
        "password":  "<password>",
        "account":   "<your_account>",
        "warehouse": "COMPUTE_WH",
        "schema":    "olap.public"
    },
    "USERS": {"analyst": "password123"},
    "USER_GROUPS": {"analyst": ["olap_users"]}
}

XLTable discovers cubes automatically from the olap_definition table — no additional cube configuration needed.

Step 3: Restart XLTable

sudo supervisorctl restart olap

Step 4: Connect Excel

Open Excel → Data → Get Data → From Database → From Analysis Services
Enter the server URL: http://your_server_ip
Log in with analyst / password123
Select myOLAPcube
Drag measures and dimensions onto the Pivot Table

What the Cube Exposes

The myOLAPcube cube provides the following fields out of the box:

Measures

Field	Description
Sales Quantity	`sum(sales.qty)` across selected filters
Sales Amount	`sum(sales.sum)` — revenue
Sales last year Quantity	Same query, dates shifted +1 year via Jinja
Sales last year Amount	Revenue for the same period last year
Average Stock Quantity	`avg(stock.qty)` per store and model
Turnover	Calculated: Sales Quantity ÷ Average Stock Quantity

Dimensions

Field	Notes
Store ID / Store	Individual retail locations
Region	North · South · East · West
Manager	Many-to-many with Region
Model	Alpha … Theta
Year / Quarter / Month / Day	`Dates` hierarchy with full drill-down

How the OLAP Cube Is Defined

The cube definition lives inside the olap_definition table as a SQL script with XLTable annotations. Each source section maps a SQL query to a set of measures or dimensions:

--olap_source Sales
SELECT
--olap_measures
 sum(sales.qty) as sales_sum_qty --translation=`Sales Quantity`
,sum(sales.sum) as sales_sum_sum --translation=`Sales Amount`
FROM olap.public.Sales sales
LEFT JOIN olap.public.Stores stores ON sales.store = stores.id
LEFT JOIN calendar times ON sales.date_sale = times.day_str

Year-over-year comparison is handled with a Jinja transformation — XLTable rewrites the date column at query time, no separate table or materialized view needed:

--olap_jinja
{{ sql_text | replace("salesly.date_sale",
   "TO_VARCHAR(DATEADD(YEAR, 1, TO_DATE(salesly.date_sale)), 'YYYY-MM-DD')") }}

Customising the Sample

Extend the date range to 2025

In the Times table generator, change the row count from 731 to 1096 (731 + 365), then update the cube filter:

WHERE year_str IN ('2023', '2024', '2025')

Add more stores or models

Extend the VALUES lists in the Stores / Models sections and update the MOD(..., 8) expressions in the Sales and Stock inserts to match the new total count.

Use a different schema

Replace every occurrence of olap.public with your own database and schema, and update "schema" in settings.json.

Common Issues

Database 'OLAP' does not exist

Run the first two statements manually before the rest of the script:

CREATE DATABASE IF NOT EXISTS olap;
USE DATABASE olap;

Insufficient privileges

Switch to a role that has the required privileges:

USE ROLE SYSADMIN;

Virtual warehouse is suspended

Resume the warehouse before running the script:

ALTER WAREHOUSE COMPUTE_WH RESUME;

No cubes visible in Excel

Verify the definition row exists and check that USER_GROUPS in settings.json includes "olap_users" for the connecting user:

SELECT id FROM olap.public.olap_definition;

Invalid account identifier

The account field must use the Snowflake account locator format, e.g. xy12345.eu-west-1. Find it in Snowflake UI → Admin → Accounts.

Summary

One SQL script creates a complete, realistic data model in Snowflake
XLTable reads the cube definition directly from the database — no YAML, no GUI
Excel connects natively via XMLA, with no plugins or data exports
Year-over-year and inventory turnover work out of the box

Try It Yourself

Download the sample script from the XLTable documentation and follow the steps above.

👉 Get a 30-day XLTable trial
👉 Read the full documentation

XLTable: Bringing the OLAP Experience Back to Excel on Modern Data Warehouses

XLTable — Thu, 29 Jan 2026 15:15:03 +0000

XLTable: Bringing the OLAP Experience Back to Excel on Modern Data Warehouses

)

The problem: data has grown, but users haven’t

Business users have always worked with data.

For many years, Excel was the primary tool for analysis, and it worked well as long as datasets were relatively small.

Over time, data volumes have grown dramatically. Today, meaningful analytical work often requires knowledge of SQL, Python, and modern data warehouses. These technologies are far beyond the skill set of most business users.

As a result, companies are forced to involve data engineers, analysts, or BI specialists even for simple analytical questions. This increases cost, slows down decision-making, and creates a gap between business questions and answers.

Why Excel is still alive

Despite countless predictions, Excel has not disappeared.

The reason is simple: Excel is intuitive. Pivot tables allow users to explore data freely — choosing metrics, slicing by dimensions, drilling down, and rearranging reports on the fly.

No BI tool has fully replicated this combination of flexibility, speed, and familiarity for a broad audience.

Why BI tools did not replace Excel

Modern BI tools such as Power BI, Looker Studio, or DataLens are powerful and well-designed. However, they have not become a true replacement for Excel in everyday analytical work.

In practice:

reports are often predefined,
ad-hoc analysis is limited,
semantic models require maintenance by specialists,
users lose the feeling of direct interaction with data.

When business users want to explore data independently, they still turn to Excel.

OLAP was the right idea

Many years ago, Microsoft took an important step by introducing OLAP technology.

The idea was simple:

data processing happens on a server,
heavy computations are performed centrally,
users work with data through Excel as a client.

This allowed business users to work with large datasets using familiar Excel pivot tables, while all complexity remained on the server side. OLAP dramatically improved accessibility of analytics.

Why classic OLAP stopped evolving

Traditional OLAP systems rely on pre-calculated cubes and aggregations. While this approach worked well in the past, it does not align with modern data architectures.

At the same time, columnar databases and cloud data warehouses became dominant:

ClickHouse
BigQuery
Snowflake
Redshift

These systems are extremely fast and scalable, but working with them still requires SQL, Python, or BI tools.

As a result:

OLAP provides the right user experience but is technologically outdated,
modern data warehouses are powerful but inaccessible to most users.

The idea behind XLTable

XLTable was created to bridge this gap.

Our goal is simple:

Give users the same experience they had with OLAP in Excel, but on top of modern columnar data warehouses.

Users should be able to:

open Excel,
connect to data,
build pivot tables,
work with measures and dimensions,

without learning SQL or Python.

A short overview of OLAP principles

OLAP is based on a multidimensional data model.

Conceptually, data is represented as a multidimensional cube:

Dimensions define axes (time, products, customers, regions)
Measures are stored in cube cells (revenue, quantity, average price)

When a user asks a question like “revenue by year”, they select:

one measure (revenue),
one dimension (year).

Excel pivot tables act as a client for OLAP systems, allowing users to arrange dimensions in rows and columns, apply filters, sorting, and drill-down operations.

OLAP vs columnar databases

Classic OLAP systems:

load data into cubes,
pre-calculate aggregations,
store results for fast access.

Columnar databases work differently:

data is stored in raw, column-oriented form,
aggregations are calculated on the fly,
performance is achieved through compression, parallelism, and query optimization.

Modern columnar systems are designed to compute analytical queries efficiently without pre-aggregation.

Shifting computation to the database

XLTable follows a simple principle:

All heavy computation should happen inside the database.

Instead of pre-calculating cubes, XLTable delegates aggregations and grouping to the underlying columnar database, using it exactly for what it was designed for.

XLTable acts as a semantic and protocol layer, not as a compute engine.

Open OLAP standards: XMLA and MDX

OLAP is an open technology.

Besides Microsoft, OLAP servers have been implemented by multiple vendors such as Oracle and Hyperion. The ecosystem relies on two key standards:

XMLA (XML for Analysis) — a protocol used by clients (such as Excel) to communicate with OLAP servers
MDX — a SQL-like query language for multidimensional data

When Excel works with an OLAP server, it sends XMLA requests containing embedded MDX queries.

Microsoft published the XMLA specification, making it possible to implement compatible OLAP servers.

What XLTable actually is

XLTable is a custom OLAP-compatible server that:

accepts XMLA requests from Excel over HTTP,
translates MDX queries into SQL,
executes them on modern data warehouses,
returns results back to Excel in XMLA format.

From Excel’s perspective, XLTable behaves like a classic OLAP server.

From the database’s perspective, XLTable is a client that generates optimized SQL.

Defining the semantic model

Any OLAP system requires a semantic model:

measures,
dimensions,
and mappings to source tables.

In Microsoft OLAP, this model is defined using graphical tools in Visual Studio.

XLTable takes a different approach. The semantic model is defined using SQL-based configuration scripts.

This approach is:

simpler and more transparent,
easier to version and maintain,
explicit in terms of generated SQL,
important for performance and cost control, especially in systems like BigQuery.

Once the model is defined, users simply connect to it from Excel.

Key features of XLTable

Fully proprietary, in-house development
All data processing happens inside the database (e.g. Snowflake)
Support for multiple measure groups, dimensions, and hierarchies in a single cube
Flexible caching strategies
LDAP / Active Directory integration
Fine-grained access control:
- by measures,
- by dimensions,
- by dimension members

Performance and scalability

XLTable does not perform aggregation or grouping itself
It receives MDX from Excel, translates it to SQL, and executes it in the database
This process requires minimal server resources
Performance depends entirely on database configuration, which aligns with columnar database design
Results can be cached at user or server level

There are no artificial limits on the number of dimensions or measure groups.

A typical production configuration includes:

~30 source tables
total data volume around 2 TB
individual tables with up to 2 billion rows

What’s next

In the next article, we will walk through:

installation,
configuration,
and the first connection from Excel to XLTable.

Connect Snowflake to Excel Pivot Tables with XLTable

XLTable — Sat, 03 Jan 2026 09:57:26 +0000

How to Connect Snowflake to Excel Pivot Tables (Without BI Tools or Data Exports)

Excel is still the most popular analytics tool for business users.

Finance teams, sales managers, and executives rely on Excel Pivot Tables because they are fast, flexible, and familiar.

At the same time, modern companies store analytical data in Snowflake — a cloud data platform built for large-scale analytics.

Yet connecting Snowflake to Excel Pivot Tables is still surprisingly difficult.

Most teams rely on CSV exports, custom SQL queries, or heavy BI tools — all of which limit true self-service analytics.

In this article, we’ll explain how to connect Snowflake to Excel properly, why exports don’t scale, and why OLAP is the missing layer.

The Snowflake + Excel Gap

Snowflake is excellent at:

large-scale analytics
elastic compute
centralized data storage
governance and security

Excel is excellent at:

ad-hoc analysis
Pivot Tables
business exploration
fast decision making

But in many companies, these tools don’t work together smoothly.

A typical workflow today

Analyst writes SQL in Snowflake
Exports data to CSV or Excel
Sends files to business users
Filters change, numbers drift
Trust is lost

This workflow does not scale.

Why CSV Exports from Snowflake Do Not Scale

Exporting data from Snowflake may look simple, but it creates serious problems:

No live data
Manual refreshes
Multiple versions of truth
Broken security model
No semantic layer

Most importantly, business users don’t want raw tables.

They want Pivot Tables.

Why BI Tools Are Often Too Heavy

Power BI, Tableau, Looker, and similar tools solve some problems — but create others:

per-user licensing costs
additional infrastructure
dashboards instead of exploration
another UI to learn

Many companies discover a frustrating reality:

After dashboards are built, users still export data to Excel.

What Excel Pivot Tables Actually Need

Excel Pivot Tables do not work well with raw SQL tables.

They expect:

dimensions and measures
hierarchies
aggregations
metadata
a semantic layer

This is exactly what OLAP provides.

OLAP as the Missing Layer for Snowflake

OLAP sits between Snowflake and Excel, translating analytical data into a structure Excel understands.

Architecture: Snowflake → OLAP → Excel

How XLTable Fits Into This Architecture

This Snowflake → OLAP → Excel architecture is exactly what XLTable is built for.

XLTable is an OLAP server designed to sit between Snowflake and Excel, providing a semantic layer that Excel Pivot Tables can work with natively.

Instead of exporting data or building dashboards, XLTable allows business users to connect directly to Snowflake using familiar Excel Pivot Tables — while all data, logic, and governance remain in Snowflake.

Key principles behind XLTable

Snowflake stays the single source of truth
Business logic is defined once, centrally
Excel users work with Pivot Tables, not SQL
No CSV exports or data duplication

What XLTable Provides

XLTable implements this architecture as a production-ready OLAP layer:

OLAP cubes on top of Snowflake
Native Excel Pivot Table connectivity via XMLA
Centralized definitions for measures and dimensions
Secure, read-only access to analytical data
Scalable query generation optimized for Snowflake

From the Excel user’s perspective, nothing changes — they simply connect to a cube and start building Pivot Tables.

From the data team’s perspective, calculations, access rules, and performance are finally under control.

Typical Use Cases for XLTable

XLTable is commonly used when:

Finance teams need live P&L or revenue analysis in Excel
Sales teams analyze performance by region, product, or customer
Operations teams explore large datasets without waiting for dashboards
Data teams want to reduce BI license and maintenance costs

In all cases, Snowflake remains the backend — Excel becomes the interface.

Excel Is Still a BI Tool — When Connected Correctly

Excel is not outdated.

Disconnected Excel is.

When Excel works directly with Snowflake through an OLAP layer, it becomes a powerful, scalable analytics interface.

Summary

CSV exports from Snowflake don’t scale
BI tools are often heavier than needed
Excel Pivot Tables require a semantic layer
OLAP bridges Snowflake and Excel
XLTable provides this missing layer

See Snowflake Analytics in Excel with XLTable

If your company uses Snowflake and Excel is still the primary analytics tool for business users, XLTable provides the missing connection between them.

You don’t replace Snowflake.

You don’t replace Excel.

You simply connect them correctly.