R, meet Snowflake: Introducing Posit’s skiLift and skiPatrol Packages

Two packages for working with Snowflake from R, now maintained by Posit

I developed the two R  packages that we will cover in this blog post, through feedback and requirements heard from R users of Snowflake who wanted easier and deeper integration with the platform. These packages provide comprehensive tools to support R users to work and collaborate within Snowflake’s data platform and ML ecosystem.

If you use and write R and your data lives in Snowflake, you have probably had a version of this conversation with your IT team: I need a driver installed. Perhaps an ODBC driver, on a server you do not administer. Perhaps a JDBC driver and a JVM to go with it. Perhaps a Python environment, because the officially supported path runs through Python. None of it is difficult, exactly. It is just friction, and it sits between you and the data every time you move to a new machine, a new container image, or a new colleague's laptop.

Put plainly: before R can talk to Snowflake, something has to be installed on the machine first, and that something is usually not yours to install. So you file a ticket, you wait. When the setup changes, you do it again. When a new colleague joins, they do it, too. None of that is the analysis you were hired to do.

Today we are announcing that Posit is taking over maintenance of two R packages that remove most of that friction:

• skiLift: a DBI-compliant Snowflake connector written in R, that authenticates and communicates via the Snowflake SQL API (REST).
• skiPatrol: an R interface to Snowflake's ML platform: model registry, feature store, experiments, model monitoring, and container services.

skiLift lets R read and write data in Snowflake with no setup beyond installing an R package. skiPatrol lets the models you build in R live and run in Snowflake alongside everyone else's, instead of off to one side.

skiLift: a Snowflake driver with nothing underneath it

skiLift talks to Snowflake over its SQL API — plain HTTPS and JSON. There is no ODBC layer, no JDBC driver, no JVM, and no Python runtime. If you can install an R package and reach *.snowflakecomputing.com, you can query Snowflake. 

In other words, skiLift is written entirely in R. It is an ordinary R package, like dplyr or ggplot2, and it connects to Snowflake the same way your browser connects to a website. Nothing has to be installed on the machine first. You do not need special permissions to set it up, and there is no separate piece of software sitting underneath that can fall out of date and quietly break things.
 

library(DBI)
library(skiLift)

con <- dbConnect(
 Snowflake(),
 account   = "myorg-myaccount",
 user      = "simon",
 warehouse = "COMPUTE_WH",
 database  = "ANALYTICS",
 schema    = "PUBLIC"
)

dbGetQuery(con, "select count(*) as n from orders")

It is a DBI driver in the ordinary sense, so it behaves the way the rest of your toolkit expects. dbplyr works:

library(dplyr)

tbl(con, "orders") |>
 filter(order_date >= "2026-01-01") |>
 group_by(region) |>
 summarise(revenue = sum(amount), n = n()) |>
 arrange(desc(revenue)) |>
 collect()

That pipeline runs as SQL in Snowflake. Only the summarised result comes back to R, which is the point — you are not pulling a large table across the wire to group_by it locally.  In addition, the package adds specific translations for Snowflake functions that are not currently covered by dbplyr.  These use Snowflake-specific SQL functions, including improved array/object handling and approximate aggregations,  directly in dplyr pipelines without falling back to writing sql().

Authentication covers the methods you are likely to be required to use: key-pair JWT, programmatic access tokens, OAuth, external browser SSO. Inside the Posit Team Native App, you do not need to supply any of them: both write their own connection profile before your code runs, so dbConnect(Snowflake()) — with no arguments at all — authenticates as the Snowflake user who launched the Posit Workbench session, in that user's default role, warehouse, and database, with no credentials for you to manage.  The defaults can be overridden if needed. The same is true of sfr_connect() in skiPatrol.

Being pure R has a cost, and it is worth stating plainly: HTTPS and JSON is not the fastest way to move very large datasets from and to Snowflake. For bulk data work, skiLift auto-routes to use ADBC, if the adbcsnowflake R package and Snowflake ADBC driver are installed, detecting installation and switching to using Arrow for the fastest performance on reads and writes. That is an optional accelerator, not a hard requirement. The pure-R path is the baseline that always works, and the accelerator is there only if and when you need greater speed for larger datasets.

Expect future enhancements in skiLift in the areas of authentication, Snowflake SQL function and type support, and performance/throughput.
 

skiPatrol: R models on Snowflake's ML platform

Snowflake's ML platform and tools — model registry, feature store, experiment tracking, model monitoring — has a comprehensive Python SDK and, until recently, no R story. The workarounds that existed were ingenious but laborious: export the model to PMML or ONNX, or hand-write a Python wrapper that shells out to Rscript, or build a bespoke container per model with a plumber API in front of it.

Snowflake gives teams a shared place to keep their ML models: a record of every version, the ingredients (features & parameters) each one was trained on, and an eye on how each is behaving once it is live. It links and provides strong lineage between models and the data they are trained on. That has worked well for Python. For R, the only ways in were awkward. You could translate the model into a different format and hope nothing important was lost in translation. You could write a second version of it in Python and keep the two in step forever. Or you could wrap each model in its own bit of custom plumbing and maintain that too. A model might take an afternoon to build and a quarter to get into production, and then it needed someone to look after it indefinitely.

skiPatrol takes a different route. It wraps the snowflake-ml-python SDK through R’s reticulate package and presents an idiomatic R API on top, so you register and serve R models as R objects:
 

library(skiPatrol)

con <- sfr_connect()

fit <- lm(mpg ~ wt + hp + cyl, data = mtcars)

sfr_log_model(
 con,
 model        = fit,
 model_name   = "MPG_MODEL",
 version_name = "V1"
)

sfr_deploy_model(con, "MPG_MODEL", "V1",
service_name  = "MPG_MODEL_SVC",
 compute_pool  = "MPG_MODEL_POOL",
 image_repo    = "MPG_MODEL_IMAGES"
)

sfr_predict(con, "MPG_MODEL", newdata = mtcars[1:5, ])

sfr_log_model() serialises the fitted R model, generates the Python wrapper needed to serve it, and registers it in Model Registry for execution using  Snowpark Container Services with the R dependencies it needs. You do not write any Python.

The model that goes live is your actual R model, not a copy of it in another format. That matters most for the models that were never possible to translate cleanly, which tend to be the more interesting ones. If it runs in R, it should run in Snowflake.
The wider benefit is not really a technical one, but one of governance. Models built in R now sit in the same place as models built in Python, with the same version history, the same record of what data, code and parameters went into them, and the same alerts when something starts to drift. When someone asks what is running in production, R models are on the list. R stops being the awkward case that needs a special explanation, and nobody has to rewrite a working model in a language they do not use just to get it deployed. R models, are shared and accessible from other Snowflake APIs (e.g. Python, SQL).
The feature store follows a similar pattern — define features using dbplyr data pipelines (or SQL) in feature views from R, then generate point-in-time-correct training and inference data:

fs <- sfr_feature_store(con, database = "ANALYTICS", schema = "PUBLIC",
create = TRUE)

sfr_create_entity(fs, "CUSTOMER", join_keys = "CUSTOMER_ID")

sfr_generate_training_data(
 fs,
 spine    = spine_df,
 features = list(customer_features)
)

Registered feature pipelines are shared and accessible from other Snowflake APIs.  Python Data Scientists can re-use Features created by R users and vice-versa. There is much more in the package than we can fit in this announcement: experiment tracking, model monitoring, many-model workflows, and doSnowflake, a foreach backend that distributes and parallelises R work across Snowflake container compute.
 

Where to start

The reference for all of this is The Piste Guide to R in Snowflake, a book-length walkthrough covering both packages: connecting from your IDE, working with the Posit Native App in Snowflake, the feature store, the model registry, monitoring, end-to-end pipelines, and using Snowflake Container Services with R. If you want to understand what these packages can do, start there rather than with the reference documentation.

Both packages are on GitHub today. They are not on CRAN yet; submission is on the near term roadmap and we will share more when it happens.

# install.packages("pak")
pak::pak("posit-dev/skiLift")
pak::pak("posit-dev/skiPatrol")

What changes now

Where they live. Development moves to Posit's GitHub organization. The original Snowflake-Labs repositories will be archived and point here. Documentation will also move under Posit’s Github organization.

Who to tell. Issues and pull requests are welcome, and they are the fastest way to influence what gets attention next. I am particularly interested in hearing from people running R on Posit Workbench or Connect against Snowflake, since that combination is the one I most want to make boring and reliable. Feel free to reach out to me directly via the contacts below if you have other ideas and suggestions for R and Snowflake integration.

Credit

These two packages exist because Snowflake let me build them while I worked there (originally published as RSnowflake and snowflakeR), but they are now part of Posit’s open source ecosystem and Posit will be continuing their maintenance. Thanks in particular to Chetan Thapar at Posit and Vinay Sridhar at Snowflake for making the transfer happen, and to Kaitlyn Wells and Mats Stellwall, whose earlier work on getting R models working within Snowflake is what made me imagine that a much smoother path could be developed.

Summary and Resources

R has always been able to reach Snowflake; it just took a driver install and configuration, an IT ticket, and a wait to get there, and models built in R had no clean way to reach production once they existed.

skiLift and skiPatrol close both gaps with nothing but R packages: connect to Snowflake with one line of code you can run yourself, and put your R models in the same registry, with the same version history and monitoring, as everything your Python teams ship. Posit now maintains both, so this is a path you can build on rather than one you have to keep repaving.
 

• The Piste Guide to R and Snowflake
• Learn more about Snowflake and Posit
• Book a meeting with Posit 
• Connect with Simon on LinkedIn, email him, or visit HexField.ai. If you are at posit::conf this week, I’ll be joining virtually.  

Note: CRAN submission of these two packages is coming soon. The Posit team and I are working as quickly as possible to make all the required naming and documentation updates to a large body of work, and will be reviewing and completing the work as soon as possible after posit::conf. Please feel free to provide any feedback through the above channels.