In this round-up, we’ve targeted the key announcements for ML workloads from Snowflake Summit. The aim is to discuss what each announcement means in practice, where we've already seen these features work, where the gotchas are, and what data leaders should prioritize in H2 2026.
This round-up has been created by Mike Droog, one of our three Data Superheroes.
Real-Time ML on Snowflake: Training, Streaming Features, and A/B Testing
If you've been doing ML on Snowflake, you know the pattern:
- Store data in Snowflake
- Extract it to SageMaker/Vertex/Databricks/etc for training
- Get a model back
- Deploy it somewhere
- Serve predictions
- Try to keep the whole thing from drifting
It works. It's also painful and expensive and creates governance gaps everywhere data moves.
Snowflake is now going after the full ML lifecycle. Not just storage and inference, but training, feature serving, and experimentation too.
Cortex Training
Fine-tune LLMs directly in Snowflake. Your data stays put. Training runs on Snowflake compute. The customized model deploys natively. No data export, no external GPU cluster management, no "how do I get this model back into production with proper RBAC" headache.
For teams currently shuttling training data to external environments, this collapses three steps into one. And more importantly, your compliance team stops asking "where did the training data go?"
VS Code and Cursor Extensions for Remote ML Dev
ML engineers don't want to work in Snowsight worksheets. They want their local editor with notebooks, autocomplete, and iterative debugging. Fair enough.
New VS Code and Cursor extensions let you develop locally and execute remotely on Snowflake compute. Write your code in the editor you prefer, run it on Snowflake's infrastructure. Skip the upload-run-download-debug-repeat cycle that makes cloud ML development feel like working through a keyhole.
Streaming Feature Views
This one's for anyone running real-time models. Feature stores matter. Stale features kill model performance. If your fraud detection model is making decisions on features that are an hour old, you're an hour behind the fraudsters.
Streaming Feature Views keep features fresh. They are continuously updated as data arrives, not batch-refreshed on a schedule. The gap between "event happens" and "feature is available to model" collapses.
A/B Testing for Real-Time Models
The last piece: experimentation. You deploy a new model version. Is it actually better? Native A/B testing lets you route traffic between versions, measure the difference, and promote the winner. No custom traffic-splitting infrastructure. No external experimentation platform.
Why these four together matter
Snowflake is building a complete ML operations stack, not just the data storage underneath it. Train → serve features → deploy → experiment → iterate. All in one platform.
For teams currently stitching together Snowflake + SageMaker + a feature store + an experimentation tool: count the number of platforms where data moves, count the governance gaps at each handoff, and then evaluate whether consolidating onto one platform (with one governance model and zero data movement) changes your architecture decision.
It won't replace every ML platform for every use case. But for teams where Snowflake is already the center of gravity for data, running the ML lifecycle there too removes a lot of operational pain.
What we recommend
If you're batching features today, look at Streaming Feature Views first. The accuracy improvement from fresh features is often the highest-ROI change you can make without touching the model itself.
If you're fine-tuning externally: try Cortex Training on your next job. Compare total time (including governance and deployment) against your current workflow, not just training time.
Mike Droog is a Data Superhero and Solution Architect at Aimpoint Digital, a Snowflake partner helping teams operationalize machine learning on Snowflake. If your team is building real-time ML capabilities, we can help
