We Love Snowflake Data

Your data is already in Snowflake. You've spent years, and serious money, building pipelines, defining schemas, enforcing governance, and making it the authoritative source of truth for your business. It's clean, it's versioned, it's secured, and it's live.

So why would your BI tool make a copy of it?

That's the question we kept asking when we built Golden. The answer we kept coming back to was: it shouldn't.

The extract problem

Most BI tools were built in a world where databases were slow and network calls were expensive. The solution was to copy your data into the tool's own storage and run analytics against that snapshot. Power BI calls this Import mode. Tableau calls it an extract. The name changes. The problem doesn't.

That model made sense in 2010. In 2026, it's broken.

Snowflake is not slow. It's a cloud-native analytical warehouse built to handle complex queries at scale, with compute that spins up on demand and pricing that scales with usage. The bottleneck is not the warehouse. It never was.

But the extract habit stuck. And it creates real problems.

Your data goes stale. The moment you pull a snapshot, you're already behind. Refreshes are scheduled. They fail silently. Someone presents a dashboard at 9am using data from Tuesday's overnight job, and nobody in the room knows.

You create data silos. Every extract is a copy that isn't governed by the rules you put in place in Snowflake. Column-level security, row-level access policies, data masking: none of that follows the data when it leaves the warehouse. You've built a governance layer and then designed your tooling to route around it.

You double your costs. Now you're paying Snowflake to store and compute, and you're paying your BI vendor to store a copy and compute against it again. The only beneficiary of that arrangement is the BI vendor.

You lose trust. When the number in the dashboard doesn't match the number in the warehouse, which one is right? Usually neither. They're from different snapshots taken at different times. Data trust erodes fast when the source of truth is ambiguous.

The idea is simple: your BI tool should send queries to your warehouse and read live results. Not copy data. Not maintain its own store. Query and return.

Warehouse-native isn't a marketing term. It's a design philosophy: your BI tool is a query interface over your warehouse, not a second warehouse.

In Golden, when you connect to Snowflake, we don't copy anything. We don't cache anything (beyond the session). We query Snowflake directly. Every chart, every KPI, every filter interaction sends a query to your warehouse and reads the live result.

Your data governance rules stay in force. If a user shouldn't see salary data, they don't see it. Because Snowflake says so, not because we've tried to replicate that logic on our end. Your column masking policies, your row-level access controls, your VPC network policies: all of it applies, because the query hits Snowflake.

Your data is always current. The dashboard your CEO opens Monday morning queries Snowflake in real time. There's no refresh schedule to manage, no stale snapshot to explain away. What's in the warehouse is what they see.

And you have one source of truth. Not three. Not five. One: your Snowflake account.

The hard part: being genuinely fast

Here's where most live connectivity tools quietly cheat. They claim to query live, but the experience is so slow it's not actually usable for interactive analytics. You click a filter and wait eight seconds. You drill into a chart and wait twelve. The tool becomes technically live and practically abandoned.

Being warehouse-native only matters if the queries are fast. So we've done serious engineering work to make sure they are.

We push as much computation as possible into Snowflake. When you build a visualization with aggregations, filters, and groupings, we generate a single, well-optimized SQL query: not a series of round trips. Snowflake's query optimizer gets to do its job.

We write queries that take advantage of Snowflake's architecture. That means respecting partition pruning, using result set caching where appropriate, and generating SQL that matches the patterns Snowflake executes efficiently.

We're also thoughtful about what we don't do. We don't pull raw rows into the browser and aggregate client-side. We don't run sequential queries when a single query will do. Every query Golden sends to Snowflake is one we'd be comfortable explaining to a DBA.

Security that comes for free

One underappreciated benefit of staying in the warehouse: security becomes simpler.

With extract-based tools, securing the extracted data is its own project. You've got data sitting in the vendor's cloud, governed by the vendor's access model, subject to the vendor's breach risk. Your Snowflake security team has no visibility into it and no control over it.

With Golden querying Snowflake directly, there's no data to secure on our end. We don't hold it. Credentials are stored encrypted. Queries go to your warehouse. Results are returned to the user who made them and nowhere else. Your Snowflake audit logs are complete.

This matters for regulated industries. It matters for any company with strict data residency requirements. And it matters for any data team that's tired of explaining to legal why their BI tool has a copy of customer records.

We built this because we believe in the modern data stack

The best data teams in the world have converged on the modern data stack for a reason. dbt for transformation, Snowflake for storage and compute, strong governance through the warehouse layer. That stack works.

The BI layer should work with it, not create a parallel universe next to it.

If you've built a solid Snowflake environment, you shouldn't need an analytics tool that undermines that investment: one that makes you manage a shadow copy, break your governance rules, and explain stale numbers to your stakeholders. That's exactly the problem we built Golden to solve.

We genuinely love Snowflake data. We just think it should stay in Snowflake.