data platform

Snowflake that people actually use, where the bill has an owner and access makes sense.

We set up Snowflake accounts or move you onto one, model the data, and put Horizon Catalog governance and role design in place. After that comes the harder call: which of Snowflake's AI features you actually let into production.

platform dossierSnowflakeData platform
Vendor
Snowflake
Open table format
Iceberg v3 GA (7 May 2026), in-place v3 upgrades GA (16 Oct 2026)
Sign-in
Password-only sign-in blocked, rolling out Aug to Oct 2026 (est.)
Governance
Horizon Catalog, with Agent Identity and Semantic Studio GA
release watch
  • Password-only sign-in blocked for all usersAug to Oct 2026 (estimated)
  • Behavior change bundle 2026_07 enabled by default08 to 16 Oct 2026
connects with
in short·15-second read

We set up and run Snowflake: account and role design, migration off legacy warehouses, pipelines, models and Horizon policies for sensitive data.

Right now most accounts also need to get every user off password-only sign-in, which Snowflake is enforcing account by account, and to move drivers above the new minimum versions, since older clients might be blocked from connecting.

you probably need this if
  • The credit bill goes up every month, and nobody can say which team or warehouse is burning 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.
Ask an engineer facts checked 2026-10-25
how it runs
  1. 01Account review
  2. 02Role and policy design
  3. 03Ingestion and modeling
  4. 04Migration with parallel runs
  5. 05AI on governed data
you keep
  • Role hierarchy design. Functional and access roles stay separate, which is what makes the access review workable.
  • Warehouse sizing and resource monitors, written down, and every one has somebody who answers for it
  • Masking and row access policy set tied to tags
+ 2 more documents
who does it
Snowflake data engineerSnowflake platform architectSnowflake administrator (RBAC, cost) SnowPro Core Certification SnowPro Advanced: Data Engineer
snowflake · release timeline
  1. 01 Jun 2026 Apache Iceberg v3 and Snowflake Storage for Iceberg tables Iceberg v3 support went GA on 7 May and Snowflake storage for Iceberg tables on 1 June, both shown at Summit 2026. Outside engines can now read and write the Iceberg data that Snowflake manages, so the copy jobs between platforms can start coming out.
  2. 30 Sep 2026 Horizon Catalog, Adaptive Compute and Semantic Studio Agent Identity in Horizon Catalog went GA at Summit. Adaptive Compute followed on 16 June, on AWS first, and the docs now list select AWS, Azure and Google Cloud regions for Enterprise Edition and up. Semantic Studio, still a private preview back in June, went GA on 30 September.
  3. 02 Oct 2026 Minimum supported driver versions raised The floor went up for JDBC (3.19.1), the Python connector (3.12.3), Go (1.11.2) and Node.js (1.14.0) as of 30 September, and for .NET (4.2.0), ODBC (3.5.0) and PHP PDO (3.0.3) as of 2 October. Snowflake says clients below the minimum might be blocked from connecting, with notice first. Old drivers usually hide in BI servers and scheduled jobs nobody has touched in years.
  4. 14 Oct 2026 Snowflake CoWork (formerly Snowflake Intelligence) Same product, new name, given at Summit along with GA for MCP connectors. Artifacts went GA on 17 June and Deep Research on 7 July. Since 14 October it can hand you a PDF, Word, PowerPoint or HTML file of an analysis. You'll need the Cortex Agent code execution tool on the agent for that.
  5. 16 Oct 2026 Iceberg v2 tables can be upgraded to v3 in place ALTER ICEBERG TABLE … UPGRADE TO ICEBERG VERSION 3 keeps the table's name, privileges and downstream references. It works on Snowflake-managed tables and on external ones with CATALOG_SOURCE = ICEBERG_REST. The upgrade is permanent, though a Snowflake-managed table can be restored to v2 with Time Travel inside the retention period.
  6. today · Nov 09, 2026
  7. no date yetPassword-only sign-in blocked for all usersThis is the last phase of Snowflake's strong authentication rollout, enforced account by account with a notice giving each account its date. Every human user who signs in with a password needs a second factor, no exceptions. Service users can't use passwords at all, and LEGACY_SERVICE users get converted to SERVICE. Reader and trial accounts and Snowflake Postgres are left out.
  8. no date yetBehavior change bundle 2026_07 enabled by defaultRelease 10.37 switched 2026_07 on by default. Admins can still turn it off to opt out while they test, but Snowflake plans to make it generally enabled in a release after October 2026, and then the opt-out goes away. The 2026_08 bundle arrived in the same release, off by default, so test accounts can try it early.
  9. no date yetBehavior change bundle 2026_06 generally enabledAlso in release 10.37, 2026_06 became generally enabled. Admins can't disable it anymore, so whatever it changes is now how every account behaves.
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.

  1. chapter 01 · where it hurts

    Why teams reach out

    • The credit bill goes up every month, and nobody can say which team or warehouse is burning 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.
  2. 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
  3. chapter 03 · how it runs

    Our approach

    • Account review
    • Role and policy design
    • Ingestion and modeling
    • Migration with parallel runs
    • AI on governed data
  4. chapter 04 · where you end up

    What changes

    • Marts move once reconciliation is signed off.
    • Both engines work off one copy of the data, under access rules everyone agreed.
    • Role hierarchy design. Functional and access roles stay separate, which is what makes the access review workable.
    • Warehouse sizing and resource monitors, written down, and every one has somebody who answers for it
what we do

Our Snowflake work

6 kinds of Snowflake work, each run by engineers who have done it on live tenants.

  1. Role hierarchy, warehouse sizing, resource monitors and network policies set up so access is predictable and spend has an owner.

  2. Moves from Teradata, Oracle, SQL Server, Redshift or Hadoop, with code conversion, parallel runs and reconciliation before the old system is switched off.

  3. Ingestion with Snowpipe, connectors or partner tools, transformations in dbt or Dynamic Tables, and dimensional or data vault models your analysts can query.

  4. Tagging, masking and row access policies, sensitive data classification and access history reviews, tied to your identity provider and governance platform.

  5. 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.

  6. 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.

capability 02 / 06in production

Migration to Snowflake

Moves from Teradata, Oracle, SQL Server, Redshift or Hadoop, with code conversion, parallel runs and reconciliation before the old system is switched off.

capability 03 / 06in production

Pipelines and data modeling

Ingestion with Snowpipe, connectors or partner tools, transformations in dbt or Dynamic Tables, and dimensional or data vault models your analysts can query.

capability 04 / 06in production

Horizon governance and data protection

Tagging, masking and row access policies, sensitive data classification and access history reviews, tied to your identity provider and governance platform.

capability 05 / 06in production

Open table formats and interoperability

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.

capability 06 / 06in production

Cortex AI and agents

Cortex Agents, semantic views and CoWork set up on curated data with clear permissions, tested on real questions before business users see them.

typical situations

Snowflake situations we walk into

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
  1. 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.

  2. 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.

  3. 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 writes the customer tables, and Snowflake gets a copy every night

composite · not a client story
  1. 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.

  2. 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.

  3. Afterwhere you end up

    Both engines work off one copy of the data, under access rules everyone agreed. Nobody has to read a nightly drift report anymore.

case studies

Snowflake case studies

All case studies
approach

How a Snowflake engagement runs

We don't start a step until the last one has produced something you can check.

  1. step 01

    Account review

    We read query history and warehouse settings first, then the role grants and access history. Cost, security and performance problems all go on one list, ranked, so you know what to fix first.

  2. 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.

  3. step 03

    Ingestion and modeling

    Sources land through Openflow, Snowpipe or Fivetran. Then we build the models in dbt or Dynamic Tables, and those models are what analysts and agents actually query.

  4. 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.

  5. step 05

    AI on governed data

    Each Cortex Agent and semantic view gets its own role. We try them on real questions first, and a small group uses them before anyone else does.

architecture

Your sources feed Snowflake, Okta or Entra ID hands it the roles, and people query it

Openflow and Fivetran pull data out of the operational systems and land it in Snowflake. Roles come over from Okta or Entra ID by SCIM, and Horizon policies decide what each role gets to see. BI tools and AI agents then query the same governed data.

Your sources feed Snowflake, Okta or Entra ID hands it the roles, and people query it Openflow and Fivetran pull data out of the operational systems and land it in Snowflake. Roles come over from Okta or Entra ID by SCIM, and Horizon policies decide what each role gets to see. BI tools and AI agents then query the same governed data. 01 · SOURCES AND IDENTITY 02 · INGESTION 03 · SNOWFLAKE 04 · CONSUMERS CDC API sync load load SCIM roles policies transform governed queries semantic views MCP connector Operational databases Oracle · SQL Server ·Postgres Sf Salesforce accounts ·opportunities Okta or Entra ID SCIM users and roles Snowflake Openflow CDC · managed connectors Fivetran SaaS connectors Snowflake warehouses · Icebergtables Horizon Catalog tags · masking · rowaccess dbt dbt models staging · marts BI tools Power BI · Tableau · Sigma Cortex Agents semantic views · CoWork Claude via MCP external agentclients © Cohash · cohash.com
01 · SOURCES AND IDENTITY02 · INGESTION03 · SNOWFLAKE04 · CONSUMERS Operational databases: Oracle · SQL Server · Postgres Operationaldatabases Oracle · SQLServer ·Postgres Salesforce: accounts · opportunities Salesforce accounts ·opportunities Okta or Entra ID: SCIM users and roles Okta orEntra ID SCIM users androles Snowflake Openflow: CDC · managed connectors SnowflakeOpenflow CDC · managedconnectors Fivetran: SaaS connectors Fivetran SaaS connectors Snowflake: warehouses · Iceberg tables Snowflake warehouses ·Iceberg tables Horizon Catalog: tags · masking · row access HorizonCatalog tags · masking· row access dbt models: staging · marts dbt models staging · marts BI tools: Power BI · Tableau · Sigma BI tools Power BI ·Tableau · Sigma Cortex Agents: semantic views · CoWork CortexAgents semantic views· CoWork Claude via MCP: external agent clients Claude viaMCP external agentclients CDC API sync load load SCIM roles governed queries semantic views MCP connector © Cohash · cohash.com
use cases

Typical Snowflake projects

The work teams usually bring us, and the platforms Snowflake has to talk to while we do it.

  1. SNO-01 The Snowflake bill keeps climbing and nobody can tell you which team is running it up common request
  2. SNO-02 A Teradata or Oracle warehouse is reaching end of support. Somebody has to decide whether to renew or move. common request
  3. SNO-03 Sensitive columns are visible to more roles than they should be common request
  4. SNO-04 Spark and Snowflake teams keep copying the same data back and forth common request
  5. SNO-05 Business users keep asking to put questions to the data through CoWork or an agent, and someone has to decide what it can see common request
you keep

What a Snowflake engagement leaves behind

These are working documents, written against your configuration, so your team can run them without us.

  • design01

    Role hierarchy design. Functional and access roles stay separate, which is what makes the access review workable.

    yours to keep
  • document02

    Warehouse sizing and resource monitors, written down, and every one has somebody who answers for it

    yours to keep
  • guide03

    Masking and row access policy set tied to tags

    yours to keep
  • code04

    A log of each script we converted, and the reconciliation results for every mart, so sign-off has something to point at

    yours to keep
  • tests05

    Semantic views, plus the test questions we ran on Cortex Agents or CoWork and what came back

    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.

Onsite

Engineers at your sites in the US

Nearshore

Overlapping hours with US teams

Offshore

Overnight progress on your backlog

All time zones

Coverage handed over across time zones

24-hour coverage · US Central time
OnsiteUS business hours
Nearshoreoverlapping US hours
Offshoreovernight progress
Combinedhandover, not hand-off
certifications our engineers hold
  • SnowPro Core CertificationSnowflake
  • SnowPro Advanced: Data EngineerSnowflake
  • SnowPro Advanced: ArchitectSnowflake
  • SnowPro Advanced: AdministratorSnowflake
roles we staff
  • Snowflake data engineer
  • Snowflake platform architect
  • Snowflake administrator (RBAC, cost)
  • Snowpark developer
  • Snowflake Cortex AI developer
  • Snowflake migration engineer
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. If you already have v2 tables, you can upgrade them to v3 in place, but there's no going back except through Time Travel.

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.

04Can AI agents query our Snowflake data safely, or do they see too much?

They can, as long as agents go through the same roles and masking policies people do. We give each agent its own role and build semantic views on definitions the business has agreed. Logging goes on, and we test with real questions before anyone outside the pilot gets access.

05Do you also work with Databricks?

Yes. Plenty of teams run both. We help sort out which workloads sit where, and whether the two share data through Iceberg or Delta Sharing.

06When does Snowflake block password-only sign-in?

Snowflake is enforcing it account by account over an estimated August to October 2026 window, and each account gets a notice with its own date. After that, every human user signing in with a password needs a second factor, and service users can't use passwords at all. Check for TYPE=LEGACY_SERVICE users first. They get converted to SERVICE, so whatever still logs in with them by password stops working.

07Our Snowflake drivers are old. Which versions does Snowflake still support?

Snowflake's minimums are now JDBC 3.19.1, Python connector 3.12.3, Go 1.11.2, Node.js 1.14.0, .NET 4.2.0, ODBC 3.5.0 and PHP PDO 3.0.3. Anything older might be blocked from connecting once Snowflake gives notice. Don't install the minimum, though. Snowflake only fixes bugs in the latest versions, so upgrade to the current release.

services

Related services

Projects on Snowflake usually end up touching one of these, so they're worth a look.

fact-checked Checked against vendor and official documentation last checked 2026-10-25 content fingerprint 3e748d75
  1. 01Book a 30-minute working sessionsenior engineer
  2. 02Talk to an engineer about your setupreply within 24 hours
  3. 03See how similar projects wentcase studies
Reviewed by the Cohash team Snowflake is a trademark of its owner, used here to identify the platform. how we handle facts and data →
next step

Tell us what you're running. We'll tell you what we'd do first.

A 30-minute working session with a senior engineer. No slides.

useful to bring
  • The platform and the version you're on
  • Where you need to get to, and by when
  • What's custom: rules, plugins, integrations
  • Any audit finding or deadline driving it