Snowflake's consumption model is designed to make it easy to start and expensive to scale. Virtual warehouses bill per second with a 60-second minimum, which means every dashboard refresh pays an idle tax whether the query needed a full minute of compute or not. Features like Dynamic Tables, Automatic Clustering, and Search Optimization add charges quietly in the background. By the time most teams audit their Snowflake bill, 30-50% of their credit consumption is coming from workloads that never needed to hit Snowflake in the first place.
Dremio doesn't require you to replace Snowflake. You layer it on top, intercept the repetitive queries that drive the highest credit consumption, and serve them from Autonomous Reflections on your own storage. The result: most teams see 40-60% lower Snowflake compute costs within the first month.
This guide walks through the cost reduction strategy, shows you how to set it up, and explains the modern AI features that make Dremio more than just a query accelerator.
Explore this interactive demo and see how Dremio's Intelligent Lakehouse enables Agentic AI
This company’s BI team was connecting Tableau directly to Snowflake, and paying for it. Dashboards were slow, queries were timing out, and lost connections on large multi-year data extracts were routine. Every new or modified dashboard required a data engineer, creating a bottleneck that slowed the entire analytics org. After routing queries through Dremio instead of directly to Snowflake, the timeouts and failures stopped. The BI team regained independence, running ~9,400 Dremio jobs per day and giving 1,200 daily users fast access to 70+ data sources, without increasing Snowflake compute.
“[with] Dremio performance and it being faster, and no longer depending on data engineering, that was an acceleration of our turnaround time”
— Stephen Brehm, Manager of Business Intelligence, ABC Supply
Snowflake charges for three things: compute (credits), storage, and data transfer. Compute is where the money goes. A Medium warehouse consumes 4 credits per hour. At $3/credit on Enterprise, that is $12/hour. Run it 12 hours a day, five days a week, and you are at $3,120/month for a single warehouse.
The problem compounds with BI dashboards. Every time a user opens a dashboard, every chart on that page fires a SQL query against Snowflake. Ten users opening the same dashboard simultaneously means ten queries. If the warehouse auto-suspended, it resumes and bills a minimum 60 seconds of compute, even if each query takes 2 seconds.
| Cost Driver | What Happens | Typical Impact |
|---|---|---|
| 60-second minimum billing | Short queries from BI tools pay for a full minute of compute | 30-50% of credit consumption on interactive workloads |
| Dynamic Tables | Background refreshes consume serverless credits silently | 10-20% of total spend for teams using materialized views |
| Automatic Clustering | Ongoing micro-partition reorganization runs in the background | $500-2,000/month per table on large datasets |
| Concurrency scaling | Auto-spins additional warehouses under load, billed on-demand | Unpredictable spikes during peak hours |
| Query optimization overhead | Cloud Services layer charges if usage exceeds 10% of daily compute | Often unnoticed until quarterly audit |
These costs are not bugs. They are structural features of Snowflake's architecture. You pay for compute whenever the engine runs, regardless of whether the query was necessary.
Dremio connects to Snowflake as a federated data source. Once connected, Dremio can query your Snowflake tables directly. The first query still hits Snowflake. But Dremio then creates Reflections, optimized Apache Iceberg copies of the query results stored on your own object storage (S3, Azure Blob, GCS).
Every subsequent query that matches a Reflection pattern gets served by Dremio's engine, not Snowflake. Snowflake never sees the query. No credits consumed. No warehouse resumed.
While all Reflections (manual or autonomous) are internally stored as Iceberg tables, those internal tables are not exposed from Dremio's catalog. Autonomous Reflections only consider datasets that are natively stored as Iceberg (or UniForm tables, Parquet datasets, and views built on them). This is why migrating your data to Iceberg over time is so important: it unlocks autonomous performance optimization.
Here is a realistic scenario for a team running 50 dashboard queries per hour against Snowflake:
Before Dremio:
After Dremio with Reflections:
Note: Dremio Cloud pricing includes both Dremio Compute Units (DCUs) and the underlying cloud infrastructure. Even accounting for both, the total is significantly less than the Snowflake spend it replaces.
The savings increase as query volume grows because Reflections serve more queries without additional Snowflake compute.
Go to Dremio Cloud and create a free account. You get a 30-day trial with full access to all features.
In the Dremio UI, navigate to Sources → Add Source → Snowflake.
Enter your Snowflake account details:
Click Save. Dremio will connect and display your Snowflake tables in the catalog.
Write a SQL view on top of your Snowflake table. This is where your semantic layer begins:
CREATE VDS my_space.sales_summary AS
SELECT
region,
product_category,
DATE_TRUNC('month', order_date) AS order_month,
SUM(revenue) AS total_revenue,
COUNT(DISTINCT customer_id) AS unique_customers,
AVG(order_value) AS avg_order_value
FROM snowflake_source.analytics.orders
GROUP BY region, product_category, DATE_TRUNC('month', order_date)Open the virtual dataset in Dremio and click the Reflections tab. You have two options:
Which type you create depends on how the data is being used. If most queries are aggregation-heavy dashboard queries, start with Aggregate Reflections. If queries scan raw rows with filters, start with Raw Reflections. You can create both if the usage patterns call for it.
Dremio queries Snowflake once to build the initial Reflection as an Apache Iceberg table on your object storage. After that, matching queries are served from the Reflection.
Go to Project Settings → Reflections → Enable Autonomous Reflections.
With this turned on, Dremio automatically monitors query patterns over the past 7 days, creates Reflections for frequently-run queries, and drops Reflections that are no longer used. No manual tuning required. The engine learns from your workload and optimizes itself.
Autonomous Reflections work with datasets natively stored as Iceberg tables (or UniForm tables, Parquet datasets, and views built on them). While all Reflections are internally stored as Iceberg, the internal Reflection tables are not exposed from Dremio's catalog. Only your natively-stored Iceberg datasets are eligible for autonomous optimization. This is another reason to migrate your data to Iceberg over time: it unlocks the full power of autonomous performance tuning.
Dremio stores your Iceberg data using the built-in Open Catalog (based on Apache Polaris), and the data remains accessible to any Iceberg-compatible engine. Your Spark jobs can still write to the same tables that Dremio is autonomously accelerating.
Dremio provisions a dedicated small engine for Autonomous Reflection jobs that automatically shuts down after 30 seconds of idle time, so you are not paying for idle compute.
The original Snowflake cost reduction story was about Reflections alone. Dremio has since added a full suite of AI capabilities that go far beyond query acceleration.
Dremio embeds Large Language Model capabilities directly into the SQL engine. Three functions are available:
| Function | What It Does | Example Use Case |
|---|---|---|
| AI_CLASSIFY() | Categorizes text data using an LLM | Sentiment analysis on customer reviews |
| AI_GENERATE() | Extracts structured data from unstructured sources | Parse PDFs, contracts, support tickets |
| AI_COMPLETE() | Summarizes data into narrative insights | Generate executive summaries from raw metrics |
-- Classify customer sentiment without exporting data SELECT customer_id, review_text, AI_CLASSIFY(review_text, ARRAY['positive', 'negative', 'neutral']) AS sentiment FROM my_space.product_reviews
In Snowflake, this type of analysis requires exporting data to an external ML pipeline, processing it with Python (often on a separate compute cluster), and loading the results back. With Dremio, it is a single SQL query. No additional compute. No data movement.
Dremio's AI Agent is embedded in the platform UI. Users type plain-English questions and the agent writes SQL, returns results, generates charts, and suggests follow-up questions. It is not a generic chatbot. It uses the semantic layer (your virtual datasets, wikis, and labels) to understand your business terminology and generate accurate queries.
For Snowflake users, this means analysts who previously needed to write complex SQL or ask a data engineer can now self-serve. That reduces the number of ad-hoc queries hitting Snowflake because the Agent works against Dremio's Reflections, not the source warehouse.
Dremio uses generative AI to auto-document your data catalog. It samples table data and schema to generate descriptions (wikis) and suggest tags (labels) for every dataset. This turns your semantic layer into a living, self-documenting asset.
For teams migrating Snowflake workloads, this accelerates the process of building documentation that would otherwise take weeks of manual effort.
Dremio's Model Context Protocol (MCP) server lets external AI tools (ChatGPT, Claude, custom agents) connect directly to your Dremio environment. This means your AI tools can query Dremio instead of Snowflake, further reducing Snowflake compute.
┌─────────────────────────────────────────────────────┐ │ BI Tools / AI Agents │ │ (Tableau, Power BI, Looker, ChatGPT) │ └──────────────────────┬──────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────┐ │ Dremio Cloud │ │ │ │ ┌──────────────┐ ┌──────────────┐ ┌────────────┐ │ │ │ Semantic │ │ Autonomous │ │ AI Agent │ │ │ │ Layer │ │ Reflections │ │ + AI SQL │ │ │ │ (Views, │ │ (Auto-learn │ │ Functions │ │ │ │ Wikis, │ │ from query │ │ │ │ │ │ Labels) │ │ patterns) │ │ │ │ │ └──────────────┘ └──────┬───────┘ └────────────┘ │ │ │ │ │ ┌────────────────────────▼────────────────────────┐ │ │ │ Apache Iceberg (Your Object Storage) │ │ │ │ Reflections stored as Iceberg tables │ │ │ └─────────────────────────────────────────────────┘ │ └──────────────────────┬──────────────────────────────┘ │ Only queries that │ miss Reflections ▼ ┌─────────────────────────────────────────────────────┐ │ Snowflake │ │ (Handles remaining 20-40% of queries) │ └─────────────────────────────────────────────────────┘
The key insight: Dremio does not replace Snowflake. It intercepts the repetitive, expensive queries that burn credits and serves them from Reflections on your own storage. Snowflake still handles complex transformations, data loading, and the queries that genuinely need its engine.
You do not need to migrate off Snowflake to reduce costs. The recommended path:
Over time, you can migrate data from Snowflake to Apache Iceberg tables on your own storage, eliminating Snowflake storage costs as well. This migration fully unlocks Autonomous Reflections, which only consider datasets natively stored in Iceberg. Dremio's Open Catalog, built on Apache Polaris, manages those Iceberg tables with full automatic table optimization (compaction, vacuuming, manifest rewriting) running in the background. And because the Open Catalog uses the standard Iceberg REST protocol, other engines (Spark, Flink, Trino) can still read from and write to those same tables. Snowflake can also query Iceberg tables natively, so data stored as Iceberg is accessible from both platforms, reducing compute and storage costs simultaneously.
| Capability | Snowflake | Dremio |
|---|---|---|
| Autonomous query acceleration | Manual materialized views with scheduled refreshes | Autonomous Reflections that learn from query patterns |
| AI SQL functions | Cortex ML functions (separate pricing) | AI_CLASSIFY, AI_GENERATE, AI_COMPLETE (included) |
| Built-in AI agent | Limited to SQL generation | Full analytical co-pilot with charts and follow-ups |
| Federated queries | Snowflake-only data | Query Snowflake + S3 + PostgreSQL + MongoDB + more |
| Open data format | Proprietary internal format (Iceberg available as second class citizen) | Native Apache Iceberg with full interoperability |
| Self-documenting catalog | Manual documentation | AI-generated wikis and labels |
The fastest way to validate the cost savings is to try it yourself:
Most teams see measurable savings within the first week. The Autonomous Reflections feature means the savings compound over time as Dremio learns your query patterns and optimizes without manual intervention.
For more on Dremio's Agentic Lakehouse platform, explore the documentation or take the free Dremio University courses.
Deploy agentic analytics directly on Apache Iceberg data with no pipelines and no added overhead.
By unifying data from diverse sources, simplifying data operations, and providing powerful tools for data management, Dremio stands out as a comprehensive solution for modern data needs. Whether you are a data engineer, business analyst, or data scientist, harnessing the combined power of Dremio and Apache Iceberg will undoubtedly be a valuable asset in your data management toolkit.
This blog helps you learn about table-driven access policies in Dremio Cloud and Dremio Software v24.1+.
Dremio Arctic bring new features to Dremio Cloud, including Apache Iceberg table optimization and Data as Code.
