Snowflake accounts with sensible costs, clear access and data people use.
Snowflake accounts set up and migrated, data modelled, Horizon Catalog governance and role design in place. Then we help decide which of Snowflake's AI features belong in production.
Apache Iceberg v3 and Snowflake Storage for Iceberg tables02 Jun 2026
Horizon Catalog updates02 Jun 2026
connects with
in short·15-second read
We implement and run Snowflake for data teams: account and role structure, migration off legacy warehouses, pipelines and models, and Horizon Catalog policies for sensitive data.
We configure Cortex AI and agents on governed data as well. Since Summit 2026 we're also planning for Apache Iceberg v3, now generally available, and for Snowflake CoWork, which is what Snowflake Intelligence is called now.
you probably need this if
Credit use keeps rising and you can't tell which team or warehouse is spending it.
Sensitive columns are readable by far more roles than anyone intended.
Snowflake roles are handed out by hand. They don't follow the groups in Okta or Entra ID.
02 Jun 2026Apache Iceberg v3 and Snowflake Storage for Iceberg tables Went GA at Summit 2026. External engines can now both read and write Snowflake-managed Iceberg data. source ↗
02 Jun 2026Horizon Catalog updates Agent Identity is GA now. Snowflake says Adaptive Compute will be generally available soon, and Semantic Studio is still in private preview. source ↗
02 Jun 2026Snowflake CoWork (formerly Snowflake Intelligence) Renamed at Summit 2026. MCP connectors generally available. Artifacts and Deep Research announced as generally available soon. source ↗
today · Oct 22, 2026
the story · snowflake estate
From the first call to a setup your own team can run.
Here's what usually prompts a call about your Snowflake estate, what we do about it and in which order, and where you end up.
01 · where it hurts02 · what we change03 · how it runs04 · where you end up
incident board · snowflake estate3 open
openCredit use keeps rising and you can't tell which team or warehouse is spending it.
recurringSensitive columns are readable by far more roles than anyone intended.
blockedSnowflake roles are handed out by hand. They don't follow the groups in Okta or Entra ID.
exposure
Account, role and warehouse designMigration to SnowflakePipelines and data modelingHorizon governance and data…Open table formats and…Cortex AI and agents
startrehearsehandover
Account review
Role and policy design
Ingestion and modeling
Migration with parallel runs
AI on governed data
we are here
ready to hand over
Marts move once reconciliation is signed off.
There's one copy of the data, with agreed access rules, and both engines use it.
Role hierarchy design with functional and access roles kept separate
Warehouse sizing and resource monitor plan, each with an owner
chapter 01 · where it hurts
Why teams reach out
Credit use keeps rising and you can't tell which team or warehouse is spending it.
Sensitive columns are readable by far more roles than anyone intended.
Snowflake roles are handed out by hand. They don't follow the groups in Okta or Entra ID.
chapter 02 · what we change
How we solve it
Account, role and warehouse design
Migration to Snowflake
Pipelines and data modeling
Horizon governance and data protection
Open table formats and interoperability
Cortex AI and agents
chapter 03 · how it runs
Our approach
Account review
Role and policy design
Ingestion and modeling
Migration with parallel runs
AI on governed data
chapter 04 · where you end up
What changes
Marts move once reconciliation is signed off.
There's one copy of the data, with agreed access rules, and both engines use it.
Role hierarchy design with functional and access roles kept separate
Warehouse sizing and resource monitor plan, each with an owner
what we do
Our Snowflake work
6 kinds of Snowflake work, each run by engineers who have done it on live tenants.
Role hierarchy, warehouse sizing, resource monitors and network policies set up so access is predictable and spend has an owner.
Moves from Teradata, Oracle, SQL Server, Redshift or Hadoop, with code conversion, parallel runs and reconciliation before the old system is switched off.
Ingestion with Snowpipe, connectors or partner tools, transformations in dbt or Dynamic Tables, and dimensional or data vault models your analysts can query.
Tagging, masking and row access policies, sensitive data classification and access history reviews, tied to your identity provider and governance platform.
Apache Iceberg tables managed by Snowflake or an external catalog, set up so Spark or other engines can read and write the same governed data.
Cortex Agents, semantic views and CoWork set up on curated data with clear permissions, tested on real questions before business users see them.
capability 01 / 06in production
Account, role and warehouse design
Role hierarchy, warehouse sizing, resource monitors and network policies set up so access is predictable and spend has an owner.
Moves from Teradata, Oracle, SQL Server, Redshift or Hadoop, with code conversion, parallel runs and reconciliation before the old system is switched off.
Ingestion with Snowpipe, connectors or partner tools, transformations in dbt or Dynamic Tables, and dimensional or data vault models your analysts can query.
Tagging, masking and row access policies, sensitive data classification and access history reviews, tied to your identity provider and governance platform.
We pieced these together from Snowflake situations that come up a lot. They're patterns. You won't find a specific client in them.
case file 01
A Teradata renewal with 9,000 BTEQ scripts behind it
composite · not a client story
Beforethe situation
A Teradata system is up for renewal, with about 9,000 BTEQ scripts and stored procedures feeding finance and risk reports. An earlier migration stopped after the first data mart because reconciliation kept failing.
What we dothe work
We inventory scripts by lineage and use and retire the ones nothing reads. The rest are converted with automated tools plus manual fixes. Each mart runs in parallel with row and aggregate reconciliation until finance signs off, then old feeds are switched off one at a time.
Afterwhere you end up
Marts move once reconciliation is signed off. Scripts nobody uses never reach Snowflake. Teradata is retired on a dated plan.
case file 02
Spark and Snowflake both holding the same customer tables
composite · not a client story
Beforethe situation
Data engineering writes customer and event tables in Spark on Databricks, and analysts copy them into Snowflake every night. The copies drift, masking rules differ between platforms, and storage is paid twice.
What we dothe work
We settle catalog ownership first, then set up Iceberg tables that both engines read and write. Masking and row access policies are set in Snowflake, Spark access goes through catalog permissions agreed with security, and the nightly copy retires after a parallel run.
Afterwhere you end up
There's one copy of the data, with agreed access rules, and both engines use it. No more nightly drift reports.
We don't start a step until the last one has produced something you can check.
step 01
Account review
We go through query history and warehouse settings first, then role grants and access history, and rank what needs fixing for cost, security and performance.
step 02
Role and policy design
Functional and access roles map to Okta or Entra ID groups over SCIM. For sensitive data, we use Horizon tags along with masking and row access policies.
step 03
Ingestion and modeling
We land sources through Openflow, Snowpipe or Fivetran, and build the models that analysts and agents query in dbt or Dynamic Tables.
step 04
Migration with parallel runs
When we migrate, the converted code runs next to the old warehouse until the reconciliation reports match. The old system stays on until then.
step 05
AI on governed data
Cortex Agents and semantic views are set up with their own roles, tested on real questions and opened to a small group first.
ai on snowflake
Where AI fits on Snowflake, and where it needs guardrails.
Snowflake keeps its AI inside the platform: Cortex Agents, Cortex Analyst and Cortex Search over governed data, and CoWork (formerly Snowflake Intelligence) for business users. Horizon Catalog adds Agent Identity, which is generally available now. A Snowflake-managed MCP server exposes those same tools to outside clients. So what any agent can see comes down to role design.
AI agentasks for data or an action
Scoped identityonly the access it needs
MCP serverthe one door into the platform
Logged, approveda person signs off on writes
Snowflakedoes the work
Snowflake offers a Snowflake-managed MCP server that exposes Cortex Agents, Cortex Search, Cortex Analyst, SQL execution and custom functions as tools, with OAuth by default. Access to the server doesn't grant its tools, so each needs its own grant. We use a dedicated least-privilege role, never PUBLIC, and keep SQL read-only.
Cortex Agents and semantic views
Cortex Agents answer questions with Cortex Analyst (it writes SQL against semantic views) and Cortex Search for documents. Before any of that, we get metric definitions agreed in the semantic views. Then we test the agents on real questions and only then open them to a small group.
Snowflake CoWork
CoWork is Snowflake's agent for knowledge workers. Until Summit 2026 it was Snowflake Intelligence. Its MCP connectors are generally available. We set it up on curated data with dedicated roles, and anything announced as coming soon stays out of production.
Agent Identity in Horizon Catalog
Agent Identity is generally available, so agents can carry their own identity under Horizon policies. We give each agent a least-privilege role with masking and row access policies. Then we review its query history the way we'd review a service account's.
AI-assisted warehouse migration
On Teradata and other warehouse moves, we use models to explain BTEQ scripts and stored procedures and to draft Snowflake SQL. Reconciliation queries prove each converted job before its old version gets switched off.
Where Snowflake sits between your sources, identity provider and consumers
Openflow and Fivetran load data from operational systems into Snowflake, and Horizon policies control what each role sees. The roles come from Okta or Entra ID through SCIM. BI tools and AI agents query the same governed data.
These are working documents, written against your configuration, so your team can run them without us.
design01
Role hierarchy design with functional and access roles kept separate
yours to keep
plan02
Warehouse sizing and resource monitor plan, each with an owner
yours to keep
guide03
Masking and row access policy set tied to tags
yours to keep
code04
Migration code-conversion log with reconciliation results per mart
yours to keep
tests05
Semantic views and test questions for Cortex Agents or CoWork
yours to keep
talent and delivery · snowflake
Certified engineers, wherever you need them.
Some clients want a project team, some want a couple of engineers on theirs. Either works. Onsite, nearshore or offshore, with handovers across time zones that keep things moving.
Put these to anyone bidding on your Snowflake work. The ones who've done it answer differently from the ones who've read about it.
Q1
How will you structure roles so access is predictable and reviewable?
Privileges granted straight to users, or functional and access roles mixed together, make access reviews impossible. Get the hierarchy clear and a governance tool can provision Snowflake roles.
Q2
What will you look at before recommending warehouse sizes?
Query history, queuing and auto-suspend settings explain most cost. Resizing before reading them usually moves the cost somewhere else.
Q3
Who owns the Iceberg catalog if more than one engine writes to our tables?
With Iceberg v3 and bi-directional access generally available, the technical barrier is lower. The open question is governance: which catalog is the source of truth and whose policies apply.
Q4
How will AI agents be limited to the data their users may see?
Agent Identity in Horizon Catalog is GA, but agents still need dedicated roles, masking and semantic views. Testing with real questions shows whether answers stay inside policy.
Q5
How will you reconcile results during migration, and who signs off?
Row counts alone miss rounding, time zone and null-handling differences. Aggregate checks per report with a named business approver are what end the parallel run.
01What drives Snowflake cost?
Mostly warehouse size and running time, then storage, serverless features and AI functions. Poorly scheduled jobs and warehouses that never suspend are the common culprits. We review query history and set resource monitors before recommending changes.
02Should we use Iceberg tables or native Snowflake tables?
Native tables are simpler if Snowflake is your only engine. Iceberg makes sense when Spark, Databricks or other engines must work on the same data. With Iceberg v3 and bi-directional access now generally available, the choice depends mostly on how many engines you run and who owns the catalog.
03How long does a migration to Snowflake take?
It depends on the volume of SQL and stored procedures to convert, the number of upstream feeds and how long you need to run in parallel. We measure those in a short assessment before giving a timeline.
04Is it safe to point AI agents at our Snowflake data?
It can be. Agents have to use the same roles and masking policies people do. We give them dedicated roles, build semantic views with agreed definitions, turn on logging, and test with real questions before rolling out further.
05Do you also work with Databricks?
Yes. Lots of clients run both platforms. We help decide which workloads live where and how they share data, through Iceberg or Delta Sharing.
services
Related services
Projects on Snowflake usually end up touching one of these, so they're worth a look.
