Understanding Snowflake's Physical Table Structure:

While data appears as familiar rows and columns in Snowflake tables, its physical storage involves innovative concepts like micro-partitions and data clustering.

This section dives into these crucial elements, revealing the inner workings of Snowflake's table structure. Furthermore, it provides expert guidance on explicitly defining clustering keys for massive tables (multi-terabytes) to optimize maintenance and query performance.

micro-partitioning:%20Beyond%20Traditional%20Data%20Warehouses%3A%0A%0A%20Traditional%20data%20warehouses%20often%20struggle%20with%20static%20partitioning,%20where%20large%20tables%20are%20divided%20into%20fixed%20units%20managed%20independently.%20This%20static%20approach%20poses%20challenges%20like%20high%20maintenance%20overhead%20and%20data%20skew,%20leading%20to%20unevenly%20sized%20partitions%20and%20performance%20bottlenecks.

Snowflake Data Organization:

Snowflake stores all data within databases, each containing schemas that group logical data objects like tables and views. There are no inherent limits on their creation.

Explore the following resources to delve deeper:

Tables: Understand Snowflake's unique table structures, including micro-partitions and data clustering.
Temporary & Transient Tables: Learn about storing temporary data for specific needs like ETL or short-lived tasks.

- External Tables: Discover how to reference read-only files stored in external stages.

- Iceberg Tables: Leverage the flexible Apache Iceberg format for data in external cloud storage and utilize Snowflake as the Iceberg catalog or create tables from existing object storage files.

- Views: Access the results of a query as a virtual table through the power of views. They can combine, segregate, and protect data effectively.

- Secure Views: Enhance data privacy by using secure views to restrict access to sensitive information within underlying tables.

-Materialized Views: Improve query performance with pre-computed data stored in materialized views, derived from specified queries.

-Table Design Best Practices: Gain valuable insights on designing and managing efficient and sustainable tables.

-Cloning Best Practices: Learn the best practices and considerations for successfully cloning databases, schemas, and permanent tables within Snowflake.

-Data Storage Considerations: Discover effective strategies for optimizing data storage costs associated with Continuous Data Protection (CDP), especially for tables.

Executing Queries and DML Statements:

Warehouse Requirements: Running queries and DML statements in Snowflake requires two conditions:

-A running warehouse.
-The warehouse specified as the current warehouse for the session.

Session Scope: Each Snowflake session can only have one current warehouse at a time.
Warehouse Selection: Use the USE WAREHOUSE command to set or change the current warehouse for the session.
Query Processing: Once set, queries and DML statements within the session are processed by the current warehouse. You can view the warehouse used for each query/statement in the Classic Console's History and Worksheets pages.

Delegating Warehouse Management:

Default Access: The ACCOUNTADMIN role holds default privileges to manage all warehouses in the account (alter, suspend, describe, etc.).
Custom Role Delegation: For finer control, use the GRANT command to grant the MANAGE WAREHOUSES privilege to a custom role. This grants equivalent privileges (MODIFY, MONITOR, OPERATE) to all account warehouses.

Example: The following demonstrates delegating warehouse management to a custom role named manage_wh_role:

1. Create and Own a New Warehouse:

SQL
CREATE ROLE create_wh_role;
GRANT

CREATE WAREHOUSE ON ACCOUNT TO ROLE create_wh_role;
GRANT ROLE create_wh_role TO ROLE SYSADMIN;
CREATE ROLE manage_wh_role;
GRANT MANAGE WAREHOUSES ON ACCOUNT TO ROLE manage_wh_role;
GRANT ROLE manage_wh_role TO ROLE SYSADMIN;
Use code with caution. Learn more

2. Use manage_wh_role to modify "test_wh" owned by create_wh_role:

SQL
USE ROLE manage_wh_role;
ALTER WAREHOUSE test_wh ...;

Delegating Warehouse Management with Roles:

This example demonstrates creating two roles to manage Snowflake warehouses:

1. create_wh_role:

This role has the CREATE WAREHOUSE privilege, allowing it to:

Create and own new warehouses.
Grant ownership of warehouses to other roles.

2. manage_wh_role:

This role has the MANAGE WAREHOUSES privilege, granting it comprehensive control over all warehouses in the account, regardless of ownership. This includes the ability to:

Suspend and resume warehouses.
Resize warehouses.
Describe warehouse properties.

Scenario:

Create both roles and grant them the necessary privileges:
SQL
CREATE ROLE create_wh_role;
GRANT CREATE WAREHOUSE ON ACCOUNT TO ROLE create_wh_role;
GRANT ROLE create_wh_role TO ROLE SYSADMIN;

CREATE ROLE manage_wh_role;
GRANT MANAGE WAREHOUSES ON ACCOUNT TO ROLE manage_wh_role;
GRANT ROLE manage_wh_role TO ROLE SYSADMIN;
Use code with caution. Learn more

Create a new warehouse with create_wh_role:
SQL
USE ROLE create_wh_role;
CREATE OR REPLACE WAREHOUSE test_wh WITH WAREHOUSE_SIZE = XSMALL;
Use code with caution. Learn more

Switch to manage_wh_role and manage the warehouse:
SQL
USE ROLE manage_wh_role;

ALTER WAREHOUSE test_wh SUSPEND; -- Suspend the warehouse
ALTER WAREHOUSE test_wh SET WAREHOUSE_SIZE = SMALL; -- Resize the warehouse
DESC WAREHOUSE test_wh; -- Describe the warehouse properties

Managing Warehouses:

Snowflake offers two options for managing your warehouses:

1. Web Interface:

Access the Admin > Warehouses > Warehouse panel in Snowsight.

In the Classic Console, navigate to Warehouses > Create.

2. DDL Commands:

Utilize the CREATE WAREHOUSE command.

Warehouse Creation:

Specify the initial state of the warehouse during creation:

Started: Resources provisioned immediately, incurring credit consumption.
Suspended: Delayed resource provisioning, minimizing initial costs.

Starting and Resuming Warehouses:

Initial Creation: Warehouses can be started during initial creation or at any later point.
Resuming: Once created, resuming a warehouse is identical to starting.

Suspended Warehouses:

Use the following methods to resume a suspended warehouse:

Web Interface: Navigate to Admin > Warehouses > > Resume in Snowsight, or Warehouses > > Resume in the Classic Console.
SQL: Execute an ALTER WAREHOUSE RESUME command.
Startup and Credit Consumption:

Resource Provisioning: Starting typically takes seconds, but may occasionally be longer during resource provisioning.
Credit Billing: Warehouses begin consuming credits when all resources are provisioned, except in rare cases of partial provisioning where billing reflects only provisioned resources. Once remaining resources are provisioned, full billing resumes.
Billing Minimum: Resumes incur a 1-minute minimum billing, though usage is reported in hourly increments.

SQL Processing:

Snowflake delays executing submitted statements until all resources are provisioned, except during rare provisioning failures.
Partial Provisioning: In such cases, processing begins once 50% or more of resources are available.

Suspending Warehouses:

Running warehouses can be suspended at any time, even during active SQL execution. This action halts credit consumption upon resource shutdown.

Suspension Methods:

Web Interface: Navigate to Admin > Warehouses > > Suspend in Snowsight or Warehouses > > Suspend in the Classic Console.
SQL: Execute an ALTER WAREHOUSE SUSPEND command.

Suspension Process:

Idle Resource Shutdown: Snowflake immediately closes all idle compute resources.
Active Statement Completion: Resources actively executing statements are allowed to finish.
Resource Shutdown & Suspension: Upon statement completion, remaining resources shut down, transitioning the warehouse to "Suspended" status.

Note: Resources awaiting shutdown are in "quiesce" mode.

Resizing Warehouses for Dynamic Resource Allocation:

Snowflake empowers you to adjust warehouse size (up or down) at any time, even during active query processing.

Resizing Methods:

Web Interface:
Snowsight: Navigate to Admin > Warehouses > > Edit.
Classic Console: Access Warehouses > > Configure.
SQL: Execute ALTER WAREHOUSE SET WAREHOUSE_SIZE = .

Benefits of Resizing Up:

Consider increasing warehouse size to enhance performance in scenarios like:

Executing large, complex queries against extensive datasets.
Loading or unloading significant data volumes.

Scaling Warehouse Resources:

Snowflake offers two approaches to scaling warehouse resources:

Vertical Scaling (Resizing): Increase compute resources within a single warehouse. Improves performance, especially for large complex queries, and reduces queuing due to resource limitations.

Note: Resizing is not intended for handling high concurrency; consider additional warehouses or multi-cluster options.

Horizontal Scaling (Adding Clusters): Requires Snowflake Enterprise Edition and expands a multi-cluster warehouse with additional compute units.

Resizing Considerations:

Limited benefit for small, basic queries. Larger size doesn't guarantee faster execution.
Running queries unaffected. Resizing only impacts queued and new queries after additional resources are provisioned.

5XL/6XL to 4XL or smaller: Brief dual billing period while the old warehouse shuts down.

Multi-cluster Warehouses Improve Concurrency

Leveraging Multi-Cluster Warehouses:

Snowflake Enterprise Edition users can opt for multi-cluster warehouses specifically designed to handle:

High concurrency: Ideal for scenarios with numerous concurrent users or queries.
Dynamic workloads: Adapts automatically to fluctuating user/query demands.

Considerations for Multi-cluster Warehouses:

Configuration:
Enterprise Edition users: Configure all warehouses as multi-cluster.
Mode: Prefer Auto-scale for automatic cluster adjustments (unless Maximized mode is vital).

Number of Clusters:
Minimum: Keep default (1) for on-demand scaling. Increase for high-availability needs.
Maximum: Set based on warehouse size and anticipated costs. Consider potential credit consumption with all clusters running concurrently.

Warehouse creation requires careful consideration of two key factors for optimal cost and performance:

1. Warehouse Size: Determines available compute resources, with larger sizes offering increased processing power but higher ongoing costs.

2. Management Approach: Choose between manual control over warehouse state (e.g., start/resume/suspend) or automated options for flexibility and resource optimization.

Multi-cluster Warehouses: For users with Snowflake Enterprise Edition (or higher), the number of clusters within a warehouse adds another layer of scalability beyond size. Further details on this advanced feature are available in the "Scaling Up vs Scaling Out" section of this topic.

Selecting an Initial Warehouse Size

Choosing the Initial Warehouse Size:

The optimal warehouse size depends on its intended function and processing workload. Consider these guidelines:

Data Loading: Match size to the number and size of files being loaded. See "Planning a Data Load" for details.
Small-Scale Testing: X-Small, Small, or Medium sizes are typically sufficient.
Large-Scale Production: Larger sizes (Large, X-Large, etc.) may be more cost-effective.

However, remember:

Per-second billing and auto-suspend allow starting large and adjusting down as needed.
Decreasing size is always possible.
Larger isn't always faster for simple queries. They may not benefit from additional resources, regardless of concurrency.

In general:

Aim to match warehouse size to the expected size and complexity of queries.

Automatic Warehouse Suspension:

Snowflake allows enabling automatic suspension based on a specified period of inactivity (minutes, hours, etc.). We recommend tailoring this setting to your workload and availability requirements:

Frequent Workloads: Consider a low inactivity threshold (e.g., 5-10 minutes) to minimize unnecessary credit consumption through per-second billing.
Gaps in Queries: Ensure the threshold aligns with natural gaps in your workload to avoid frequent and resource-intensive suspension/resumption cycles (minimum 60 seconds billed each time).
Heavy Workloads: Disable auto-suspension for warehouses with continuous processing needs or zero tolerance for delays. Note that provisioning time, though typically fast (1-2 seconds), can vary based on warehouse size and available resources.

Automatic Warehouse Resumption:

Snowflake offers automatic resumption upon receiving new queries. We recommend tailoring this setting based on your desired control over usage:

Priority on Convenience: Enable auto-resume for immediate availability even with potential minor provisioning delays. This reduces manual intervention but may incur unnecessary costs if unused.
Focus on Cost Control or Access: Disable auto-resume and manually initiate restarts. This provides granular control over resource utilization and user access but requires proactive management.

Warehouse Caching:

Active warehouses maintain a table data cache, improving subsequent query performance by reducing table reads.
Cache size scales with warehouse compute resources: larger warehouses have larger caches.
Suspending a warehouse drops the cache, potentially impacting initial query performance upon resumption.
Resumed warehouses rebuild the cache: queries benefit as the cache grows.

Consider this trade-off:

Suspend to save credits: immediate cost savings, but potentially slower initial queries.
Leave running to maintain cache: faster initial queries, but ongoing credit consumption.

Query Processing and Warehouse Size:

Resource demand: Compute requirements for queries depend on their size and complexity.
Scaling: Generally, queries scale linearly with warehouse size, especially complex ones.

Key factors:
Table size: Overall size outweighs the number of rows.
Filtering: Predicates affect processing, as does the number of joins/tables.
Optimization tip: Execute similar queries (size, complexity, data) on the same warehouse. Mixed workload diversity complicates load analysis and optimal size selection.

Credit Billing:

Computed based on:
-Warehouse size (credits per hour per cluster)
-Number of clusters (multi-cluster only)
-Running time of individual cluster resources
Example: X-Small (1 credit/hour/cluster), 4X-Large (128 credits/hour/cluster).

Billing Notes:

-Minimum: 1 minute for initial resource provisioning.
-Stopping: No benefit before 60 seconds (initial charge already incurred).
-Per-second: After 60 seconds, billing increments by the second.
-Restarting: Credits accumulate across restarts under 60 seconds.
-Resizing: Increases billing proportionally while additional resources run.

5XL/6XL → 4XL or smaller: Brief overlap billing while old warehouse shuts down.

Credit Display:

Shown in hourly increments, but reflects fractional usage due to per-second billing.

1. Introduction:

This guide presents general best practices for leveraging virtual warehouses in Snowflake for efficient query processing. It refrains from absolute recommendations as optimal configurations depend on diverse factors, including:

- User/query concurrency
- Number of accessed tables
- Data size and structure
- Specific needs for availability, latency, and cost

Warehouse considerations for data loading are addressed in a separate topic (see sidebar).

2. Key Principles:

Experimentation: Execute diverse queries on various warehouse sizes to identify your ideal setups for specific workloads.
Size Flexibility: Prioritize efficient resource utilization over constant warehouse sizing. Snowflake's per-second billing allows suspending larger warehouses (Large, X-Large, etc.) during inactivity, minimizing cost.

3. Conclusion:

By implementing these principles, you can optimize warehouse usage and achieve cost-effective, high-performance query processing in Snowflake.

Note: These guidelines encompass both standard single-cluster warehouses and the advanced multi-cluster warehouses offered in Snowflake Enterprise edition.

1. Warehouses: Essential Processing Units

Snowflake virtual warehouses serve as the core computational units responsible for running all SQL queries and data manipulation language (DML) operations, including loading, unloading, and updating data within tables.

2. Warehouse Properties and Functionality

Each warehouse is characterized by two key attributes:

Type: Categorized as either Standard or Snowpark-optimized, catering to different workload requirements.
Size: Defines the available compute resources, measured in virtual CPUs and memory.
Additionally, various configurable properties enable granular control and automation of warehouse activity.

3. Dynamic Resource Management

Snowflake offers unparalleled flexibility in managing warehouses:

Start and Stop on Demand: Warehouses can be activated and deactivated instantly as needed.
Responsive Scaling: Resizing is possible at any time, even during active operation, to adjust compute resources according to the intensity and type of warehouse tasks.

Warehouse Size:

Determines available compute resources per cluster.
Sizes: X-Small to 6X-Large, with increasing credits per hour and second.
Notes:
X-Small and Small are defaults for Snowsight and CREATE WAREHOUSE.
X-Large is default for Classic Console.
5X-Large and 6X-Large are in preview for US Government and Azure regions.
Impact on Credit Usage and Billing:

Billing: Per-second, with a 60-second minimum on startup.
Impact: Doubles with each size upgrade per full hour.
Example: Credits consumed for different sizes with varying running times.
Impact on Data Loading:

Increasing size doesn't always improve loading performance.
Tip: Smaller warehouses (Small-Large) suffice for most scenarios.
Impact on Query Processing:

Larger size can improve execution time, especially for complex queries.
Resizing: Provides more resources for running and queued queries.
Tip: Large size not necessarily faster for small, basic queries.
Auto-suspension and Auto-resumption:

Auto-suspend: Deactivates warehouse after inactivity (default enabled).
Auto-resume: Activates warehouse on incoming query (default enabled).
Benefit: Simplifies monitoring and usage, avoiding unnecessary credit consumption.
Query Processing and Concurrency:

Warehouse size and query complexity determine concurrent queries.
Queued queries: Wait for resources as others complete.
Control mechanisms: STATEMENT_QUEUED_TIMEOUT_IN_ SECONDS and STATEMENT_TIMEOUT_IN_SECONDS.
Alternatives: Create new or resize existing warehouse, or leverage multi-cluster warehouses (Enterprise Edition).
Warehouse Usage in Sessions:

Sessions initially lack associated warehouses, preventing queries.
Default warehouses:
User-specific: Set during creation/modification.
Client utilities/drivers/connectors: Specified in configuration files or connection parameters.
Precedence: User > Client defaults > Command line/driver parameters.
Change: USE WAREHOUSE command within a session.

Imagine Snowflake as a vast data lake, and virtual warehouses as your handy boats. These "warehouses" are actually clusters of processing power, available in two flavors: the trusty Standard and the cutting-edge Snowpark-optimized. These boats equip you with the muscle (CPU and memory) and temporary storage needed to sail through various tasks in your Snowflake journey:

Dive into data: Run SELECT statements to retrieve rows from tables and views like treasures from the depths.
Shape your data: Craft your data with DML operations like updating rows, inserting new ones, or simply unloading them onto dry land.
Bring data aboard: Load fresh data into your tables, filling your boat with new discoveries.
So, whether you're a seasoned data explorer or just setting sail, virtual warehouses are your ticket to navigating the Snowflake data ocean efficiently and effectively.

Heads up! These operations need a running warehouse, and active warehouses chew through Snowflake credits.

1. Overview of Warehouses

Virtual warehouses are the computational units in Snowflake responsible for executing all SQL queries and Data Manipulation Language (DML) operations (e.g., loading, unloading, updating data).
Warehouses are categorized by type (Standard or Snowpark-optimized) and size, with additional properties enabling control and automation.

2. Snowpark-optimized Warehouses

While both Standard and Snowpark-optimized warehouses can handle Snowpark workloads, the latter is optimized for scenarios with significant memory demands, such as machine learning training.

3. Warehouse Considerations

This section presents best practices and general guidelines for managing virtual warehouses effectively in Snowflake to optimize query processing.

4. Multi-cluster Warehouses

Multi-cluster warehouses provide dynamic scaling of compute resources to address fluctuating user and query concurrency demands, particularly during peak or off-peak periods.

5. Working with Warehouses

This section offers comprehensive guidance on creating, stopping, starting, and managing Snowflake warehouses efficiently.

6. Using the Query Acceleration Service

The Query Acceleration Service can enhance performance by offloading resource-intensive portions of queries in a warehouse. Enabling it can improve overall warehouse efficiency by mitigating the impact of outlier queries.

7. Monitoring Warehouse Load

Warehouse query load provides insights into the average number of concurrent or queued queries within a specified timeframe, enabling performance analysis and optimization.

SnowSQL serves as the command-line interface for connecting to Snowflake, enabling the execution of SQL queries and performing various DDL and DML operations, including data loading and unloading from database tables.

The snowsql executable, representing SnowSQL, can operate either interactively as a shell or in batch mode through stdin or the -f option.

While SnowSQL is an application developed using the Snowflake Connector for Python, it's important to note that the connector is not mandatory for SnowSQL installation. All necessary software for SnowSQL is bundled within the installers.

Snowflake offers platform-specific versions of SnowSQL for download, catering to the following platforms:

Operating System

Supported Versions

- Linux

- CentOS 7, 8

- Red Hat Enterprise Linux (RHEL) 7, 8

- Ubuntu 16.04, 18.04, 20.04 or later

- macOS 10.14 or later

- Microsoft Windows

- Microsoft Windows 8 or later

- Microsoft Windows Server 2012, 2016, 2019, 2022

Related Videos:

How to Install, Configure & Use SnowSQL

This section offers general information on using the Classic Console.

Browser Requirements:

Access the Snowflake Classic Console using any of the following browsers with their respective minimum versions:

- Chrome: 47
- Safari: 9
- Firefox: 45
- Opera: 36
- Edge: 12

The Classic Console offers the ability to execute tasks typically carried out using SQL and the command line. These tasks include:

1. Creation and management of users and other account-level objects (requires the appropriate administrator roles).
2. Establishment and utilization of virtual warehouses.
3. Creation and modification of databases and all associated database objects (schemas, tables, views, etc.).
4. Data loading into tables.
5. Submission and monitoring of queries.
6. Password changes and adjustment of user preferences.

For guidance on transitioning from the Classic Console to Snowsight, please refer to the "Upgrading to Snowsight" documentation.

About Snowsight:

Snowsight introduces enhanced and expanded functionality within the user interface, encompassing the following:

1. Granular usage views for effective cost governance.
2. One-click capability to enable database replication to other regions.
3. Comprehensive management of users, accounts, and privileges.
4. Worksheet organization through folders.
5. Autocomplete feature for database objects and SQL functions in worksheets.
6. Dashboards equipped with built-in visualizations.
7. Collaboration and sharing functionalities for worksheets and dashboards.
8. Improved data sharing capabilities, including sharing with other accounts or publicly on the Snowflake Marketplace through listings.

It's noteworthy that no significant new features have been introduced in the Classic Console since April 2022.

Snowsight is Set as the Default for an Account:

When Snowsight is designated as the default interface for an account, individual users lose the ability to set a default web interface within their user profiles. Despite this, all users maintain access to the Classic Console after logging in to Snowsight.

Please note:

As part of behavior change bundle 2023_08, customers with a Capacity commitment have the option to enable the bundle, setting Snowsight as the web interface for their account.

For additional information regarding the impact of this change, refer to Snowsight: Default interface for all users in Standard Edition accounts (Pending).

To understand more about the behavior change bundle process, consult About Behavior Changes.

You Can Choose the Default Web Interface for Your User Profile:

If Snowsight isn't the default web interface for all users in your account, you have the option to designate it as the default for your user profile:

1. Log in to Snowsight.

2. Click on your username and choose "Profile."

3. Under "Default Experience," opt for Snowsight.

4. In case the option to choose a default experience isn't visible, it's likely that your default web interface is set at the account level. Refer to "Snowsight is Set as the Default for an Account."

5. Click "Save."

Once you've set Snowsight as the default for your user profile, you can still access the Classic Console if necessary by using the Classic Console option in the menu.

Please be aware:

Due to modifications introduced in behavior change bundle 2023_04, every new user added to a Snowflake organization will have Snowsight configured as the default experience for their user profile. Further details can be found in the document Snowsight: Default Interface for New Users.

This section provides an introduction to getting started with Snowsight, the web interface for Snowflake. If you are looking to transition from the Classic Console to Snowsight, please consult the "Upgrading to Snowsight" guide.

Browser Requirements:

Snowsight is compatible with the most recent three major versions of the following web browsers:

Apple Safari for macOS
Google Chrome
Microsoft Edge
Mozilla Firefox

Accessing Snowsight Through a Proxy or Firewall:

To establish access to Snowsight via a proxy or firewall, it may be necessary to include the fully qualified URL and port values in the configuration settings of the proxy servers or firewall.

To identify the fully qualified URL and port for Snowsight, examine the SNOWSIGHT_DEPLOYMENT entry within the return value of the SYSTEM$ALLOWLIST function.

Signing in to Snowsight:

You have the option to connect to Snowsight either via the Internet or by utilizing private connectivity to the Snowflake service.

Using the Internet:

To access Snowsight via the public Internet, follow these steps:

1. Open a supported web browser and go to https://app.snowflake.com.

2. Enter your account identifier or account URL. If you've logged into Snowsight before, you may see an account name that you can choose.

3. Sign in using your Snowflake account credentials.

Alternatively, you can access Snowsight from the Classic Console:

Log in to the Classic Console.

In the navigation menu, choose Snowsight.

Snowsight will open in a new tab.

Using Private Connectivity:

Upon completing the setup for private connectivity, follow these steps to access Snowsight:

To sign in directly to Snowsight using private connectivity, especially if you haven't logged in to the Classic Console before:

Enter one of the following URLs into the browser location bar:

https://app-orgname-account_name.privatelink.snowflakecomputing.com
https://app.cloud_region_id.privatelink.snowflakecomputing.com
(Replace orgname with your Snowflake organization's name, account_name with your account's unique name, and cloud_region_id with the cloud region identifier.)

After signing in, you can retrieve these details by hovering over an account in the account selector. Refer to "Format 1 (Preferred): Account Name in Your Organization" for more information.

Note: If you are uncertain about the values to enter, please consult your internal Snowflake administrator before reaching out to Snowflake Support.

Enter your Snowflake credentials.
If you prefer to sign in to Snowsight through the Classic Console using private connectivity to the Snowflake service:

Log in to the Classic Console.

In the upper-right corner of the Classic Console, select "Snowsight."

Snowsight will open in a new tab or window.

Signing in to a Different Snowflake Account:

Navigate to the bottom of the left navigation bar and utilize the account selector to log in to an alternative account. The selector conveniently displays accounts you have accessed previously.

Using Snowsight:

This section offers a concise introduction to navigating and utilizing Snowsight, including examples and explanations of the following interface components:

1. Left navigation
2. User menu
3. Account selector

Setting User Details and Preferences:

To access your user profile, click on your username and choose "Profile."

Within your profile, you can view and adjust the following user details:

- Profile photo
- Username (unchangeable)
- First name
- Last name
- Password
- Email

Ensure your user profile includes a first name, last name, and email address, as certain Snowflake features, like accepting the terms of service for the Snowflake Marketplace, may require this information.

You can also configure the following preferences:

1. Default experience:

Choose whether to start in Snowsight or the Classic Console upon signing in. If the option to select a default experience is not visible, your default experience might be set at the account level.

2. Language:

Set the language for Snowsight. Snowflake currently supports English (US) and Japanese (日本語).

3. Notifications:

Indicate whether to receive a browser notification upon the completion of a background query. When setting this preference for the first time, your browser will prompt you to allow notifications from Snowflake.

4. Multi-factor authentication:

Decide whether to enable multi-factor authentication (MFA), which is supported by the Duo Security service.

5. Session Timeout:

Maintain a client session as long as user activity is detected. After a period of inactivity (4 hours), the session will terminate, requiring you to sign in again.

Switching Your Active Role:

When utilizing Snowsight, you have the flexibility to alter the active role within your ongoing session. Your active role dictates the visibility of databases, tables, and other objects, as well as the actions you can undertake.

To change your active role:

1. Navigate to the user menu at the top of the left navigation bar.

2. Hover over your current active role to reveal the role selector.

3. Choose the desired role that you wish to activate.

For additional information on access roles and object privileges, refer to the Overview of Access Control.

Configuring Private Connectivity for Snowsight:

Before establishing private connectivity for Snowsight, it's essential to first configure private connectivity for your Snowflake account. Refer to the dedicated guide based on the cloud platform hosting your Snowflake account—whether AWS, Azure, or Google Cloud Platform.

To enable private connectivity with Snowsight, follow these steps:

1. Utilizing the ACCOUNTADMIN role, invoke the SYSTEM$GET_PRIVATELINK_CONFIG function within your Snowflake account. Identify the values for the following:

- privatelink-account-url
- snowsight-privatelink-url
- regionless-snowsight-privatelink-url

2. Verify that your DNS settings can resolve these values.

3. Confirm connectivity to Snowsight using each of these URLs from your web browser.

If you wish to use the account name URL (regionless-snowsight-privatelink-url) as your primary access point to Snowsight, contact Snowflake Support. Request that all URL redirects be directed to the specified URL for regionless-snowsight-privatelink-url.

Snowsight simplifies Snowflake's robust SQL capabilities into a cohesive, user-friendly experience. Employ Snowsight for essential Snowflake operations, including:

1. Crafting and executing queries.
2. Monitoring query performance and copy history.
3. Generating and overseeing users and other account-level entities.
4. Establishing and utilizing virtual warehouses.
5. Establishing and altering databases and all associated database objects.
6. Collaborating on data with other Snowflake accounts.
7. Navigating listings and sharing data publicly on the Snowflake Marketplace.

Utilize Snowsight to administer your account and user profile. This includes tasks such as enabling multi-factor authentication, updating your password, and managing your user preferences.

To set up a trial account with any Snowflake partner currently available in Partner Connect, follow these steps:

1. Log in to either Snowsight or the Classic Console.

2. Activate the ACCOUNTADMIN role in the interface:

- In either interface, click the dropdown menu next to your login name.
- Choose "Switch Role » ACCOUNTADMIN" to switch to the account administrator role.

3. Access the Partner Connect page:

- For Snowsight, select "Admin » Partner Connect." This opens the Partner Connect page.
- In the Classic Console, click on the "Partner Connect" tab, and the Snowflake Partner Connect page opens.

4. Click on the corresponding tile for the partner you want to connect with.

A dialog will appear, displaying the requirements for connecting to the partner and a list of objects automatically created in Snowflake during the connection process. This includes an empty database, warehouse, default user, and custom role. These objects are utilized by the partner application when interacting with your account.

5. Optionally, specify one or more existing databases in Snowflake to automatically use with the trial. This action creates an additional custom role, making existing data in Snowflake quickly available to the partner application.

If you don't specify databases during the initial connection, you can do so later, but it will be a manual task.

Important Note: The Classic Console does not currently support specifying shared databases (databases shared from provider accounts to your account) for your Partner Connect trial during the initial connection process. If you choose a shared database, the Classic Console will return an error when you click the Connect button to complete the process.

To use shared databases with a trial:

- Utilize Snowsight to finish the initial connection process.
- Manually specify the shared database after the process completes.

6. Click the Connect button below the partner description to initiate the creation of a trial account with the partner and connect the partner application to Snowflake.

Once the process is complete and the objects are created, the partner tile will be updated with a checkmark.

Partner Connect simplifies the process of generating trial accounts with designated Snowflake business partners and seamlessly integrating these accounts with Snowflake. This functionality offers a convenient avenue for experimenting with different third-party tools and services, allowing you to adopt the ones that align most effectively with your business requirements.

Supported Partners:

Crucial Information:

Snowflake does not establish or dictate the conditions or terms (such as duration, supported features, etc.) for partner trial accounts. These policies are determined independently by each Snowflake partner and may differ among partners.

For specific details regarding a particular trial, kindly reach out to the respective partner directly.

Currently, Partner Connect includes the following partners:

- alation
- alteryx
- census
- coalesce
- dataops
- dbt Labs
- Fivetran
- Hightouch
- Sigma
- zepl