Build1 publisher2 min readPublished
Nine SQL statements share a Snowflake model registry entry with another account
Snowflake's Direct Share now reaches models in the registry. A dev.to walkthrough routes one through a database role into a second account, and logs it twice because warehouse and SPCS inference do not share behaviour.
The Engineer · Build desk
What happened
- Snowflake's Direct Share now covers models in the Model Registry, according to a dev.to walkthrough that points at Snowflake's own documentation on sharing models.
- The walkthrough logs one fitted XGBoost regressor twice: v1 with no target platform argument, which the author says runs on SPCS, and v2_warehouse pinned to the warehouse with target_platforms.
- The consumer creates SHARED_ML_DB from the share, grants the inherited SHARED_ML_DB.DB_ROLE_SHARE to a local custom role, then sees the model in its own database explorer and runs inference against it.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- decision Anyone copying this has to pick between granting the model straight to the share and routing it through a database role; the second option is what lets the consumer's role tree mirror the provider's instead of being invented locally.
- constraint Whoever logs the version picks the inference compute for every downstream account, so a consumer that only runs warehouses depends on the provider having passed target_platforms upstream.
- exposure The boundary between dev, stage and prod now rests on the grant list of a single database role, and the share carrying it is created under ACCOUNTADMIN.
- cost Offering both inference paths costs a second log_model call and a second version to keep in step, in every account that consumes the share.
Two calls to log_model, one fitted model object. The version named v2_warehouse passes target_platforms=[TargetPlatform.WAREHOUSE]; v1 passes no target platform at all and, according to the author, runs on SPCS [4]. That keyword argument is set in the provider account, so the consumer receives whichever inference compute the provider picked at log time [18].
The reason for logging both is the author's own warning: sharing behaves differently depending on whether inference runs in a warehouse or on SPCS, which is why the sample builds both [2]. The post's explanation of that difference comes after the code sample, and the text available breaks off mid-import on the consumer side [19]. Anyone working from that text ends up with both versions logged and no statement of what the difference is.
Environment separation is enforced by the grant chain. The provider can grant model privileges straight to the share, or grant them to a database role and then put that role in the share [8]. The author chose the database role because it makes it easier for the consumer to reproduce the provider's role structure [9]. In practice that means USAGE on ML_SHARE_TEST.PUBLIC and USAGE on the model go to DB_ROLE_SHARE, the database and the role go to ML_MODEL_SHARE, and the consumer's account locator is added with ALTER SHARE [10]. Snowsight lists the result under External Sharing in the Data Sharing tab, with the database role included [11]. On the consumer side the role arrives namespaced under the new database, as SHARED_ML_DB.DB_ROLE_SHARE, and is granted to a local custom role [12].
The adoption cost is nine SQL statements: seven on the provider side, counting the share, the database role, four grants and one ALTER SHARE, plus two on the consumer side [17]. The share is created under ACCOUNTADMIN with SECURE_OBJECT_ONLY = FALSE [7].
The shared model is a throwaway. The spine is a 1,000-row sample and the split is test_size=0.2, so roughly 800 rows of New York taxi features train an XGBRegressor at max_depth 4 [13][16]. The author writes that accuracy is irrelevant here and the model is thrown together [14]. The detail that crosses the account boundary is sample_input_data=X_train[:10], which fixes the signature the consumer sees from ten rows [6].
On finding the feature, the author wrote: "This landed without me noticing. A good reminder that you really do have to keep up with the documentation." [15]
What to watch
- Whether Snowflake's own documentation spells out the warehouse-versus-SPCS sharing difference the post flags, and what fails in the SPCS case.
- Whether SECURE_OBJECT_ONLY = FALSE is required for a share that carries a model, or just the author's setting.
- Whether a consumer can re-target a shared model version's inference platform without the provider logging a new version.