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)

1. 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)
2. Governed collaboration: Shared Workspaces live under normal RBAC in your DB/SCHEMA, so security folks don't freak out. (Snowflake Documentation)
3. 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)
4. 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)

---