Snowflake Workspaces: The Opinionated Guide for Busy Data Teams

What’s happening (and when)

Snowflake is defaulting accounts from Worksheets to Workspaces on a rolling basis that started in September 2025 (with cohorts by edition) and will ultimately deprecate Worksheets. You can still flip back—for now—but Workspaces is the new direction. (Snowflake Documentation)

Key detail: on first use, Snowflake creates a personal database (PDB) per user to store workspace files. It’s not for tables/views; it just enables Workspaces and shows some required privileges on that internal DB. (Snowflake Documentation)

Why Snowflake is doing this (the strategic read)

Worksheets were fine for ad-hoc queries, not for software-grade analytics development. Workspaces brings a file-based, multi-language editing model with Git integration, a database explorer, split editors/results, per-file query history, and inline Copilot—i.e., a real browser IDE that lives next to the data and governance you already use. Translation: fewer context switches, better version control, and a cleaner path from experimental SQL to productionized code. (Snowflake Documentation)

What’s actually new (that you’ll feel)

Unified editor for SQL, notebooks, and more—side-by-side editing and results, run two queries at once from the same file, and improved UI performance. (Snowflake Documentation)
Git-synced workspaces: pull/push, branch, resolve conflicts directly in Snowsight (OAuth to GitHub supported with an API integration). (Snowflake Documentation)
Per-user PDB automatically created to store workspace content (no standard objects allowed). Admins will see OWNERSHIP/USAGE/CREATE SCHEMA on that PDB—needed for Workspaces, not a privilege escalation elsewhere. (Snowflake Documentation)
Shared Workspaces (Preview): team spaces as RBAC schema objects in a standard database/schema with a draft→publish model for wiki-style collab. Great middle ground between “private tinkering” and “Git-only.” (Snowflake Documentation)

The best parts (from a Fortune-500 data engineer’s lens)

Code as first-class: Files, folders, and projects beat a flat list of worksheets. This aligns analytics with software practices (reviews, branching, repeatability). (Snowflake Documentation)
Governed collaboration: Shared Workspaces live under normal RBAC in your DB/SCHEMA, so security folks don’t freak out. (Snowflake Documentation)
Git where your data lives: No more ritual ZIP exports or copy/paste from editors. Conflicts and diffs in the UI reduce friction to “do the right thing.” (Snowflake Documentation)
Operational quality: Per-file history, pinned/split results, and database explorer make investigations and RCA less painful. (Snowflake Documentation)

The fine print (real-world gotchas)

Filters (those GUI result filters) aren’t supported in Workspaces. If your analysts lean on them, you’ll need workarounds or dashboards. (Snowflake Documentation)
Old vs new UI: Editing the same worksheet in both UIs can lose changes, and role/warehouse/schema context isn’t synced between them. Pick one during transition. (Snowflake Documentation)
No sharing from private workspaces (that’s what Shared Workspaces are for). Also, workspace files don’t show in Universal Search (for now). (Snowflake Documentation)
PDB visibility: Admins will see users with OWNERSHIP/USAGE/CREATE SCHEMA on their PDB. That’s by design and not carte blanche elsewhere—plan your RBAC messaging. (Snowflake Documentation)

Admin levers you’ll actually use

Set Workspaces as default—account-wide:

ALTER ACCOUNT SET USE_WORKSPACES_FOR_SQL = 'always';

Revert (respect Snowflake’s future defaults/BCRs):

ALTER ACCOUNT UNSET USE_WORKSPACES_FOR_SQL;

Force “never” (temporarily ignore BCR defaulting to Workspaces):

ALTER ACCOUNT SET USE_WORKSPACES_FOR_SQL = 'never';

Disable Workspaces entirely by disabling personal DBs (not typical):

ALTER ACCOUNT SET ENABLE_PERSONAL_DATABASE = FALSE;

These are ACCOUNTADMIN-level controls; Snowflake has stated Worksheets will be deprecated later. (Snowflake Documentation)

RBAC for Shared Workspaces (Preview):

GRANT USAGE ON DATABASE <db> TO ROLE <role>;
GRANT CREATE WORKSPACE ON SCHEMA <db>.<schema> TO ROLE <role>;

(Snowflake Documentation)

Git via OAuth (GitHub example requires an API INTEGRATION):

CREATE OR REPLACE API INTEGRATION my_git_oauth
  API_PROVIDER = git_https_api
  API_ALLOWED_PREFIXES = ('https://github.com/')
  API_USER_AUTHENTICATION = ( TYPE = snowflake_github_app )
  ENABLED = TRUE;

Then users can create a Git-connected workspace and push/pull from Snowsight. (Snowflake Documentation)

How I’d roll this out (pragmatic plan)

Phase 0 – Decide posture (this week)

Set USE_WORKSPACES_FOR_SQL='always' in a pilot account only. Publish a “Workspaces vs Worksheets” matrix with the GUI filters note so stakeholders aren’t surprised. (Snowflake Documentation)

Phase 1 – Foundations (weeks 1–2)

Stand up Shared Workspaces in a governed DB/SCHEMA for each domain squad.
Wire Git (OAuth API integration) and define branching/publish rules (e.g., draft in shared, PRs in Git to merge to main). (Snowflake Documentation)

Phase 2 – Migration (weeks 3–6)

Sweep high-value legacy worksheets into file-based projects; codify macros, seeds, and dbt/sql assets.
Prevent “dual editing” in old UI; gate users by role to avoid conflicts. (Snowflake Documentation)

Phase 3 – Hardening (ongoing)

Add linting/CI around Git (SQLFluff/dbt build) and Workspaces push events.
Track usage/cost impacts; ensure warehouses for interactive Workspaces have sane autosuspend/min cluster settings.

When not to lean on Workspaces

Heavy BI-style filtering done in-result GUI; steer those users to Dashboards or tool-side filtering. (Snowflake Documentation)
Teams with mature local IDE + Git flows who only need ad-hoc queries. Keep Workspaces as view-only or for shared snippets.

Quick FAQ you’ll get from leadership

“Is this a security risk?” No—Shared Workspaces are schema objects governed by existing RBAC; PDBs are scoped to Workspaces and don’t grant broader access. (Snowflake Documentation)
“Can we pause the change?” Temporarily, with USE_WORKSPACES_FOR_SQL='never', but Worksheets will be deprecated—don’t bet the farm on rollback forever. (Snowflake Documentation)
“Will this replace Git?” No—embrace Git more. Workspaces makes Git practical for everyone. (Snowflake Documentation)