In Snowflake’s logical hierarchy, tables reside within schemas, and schemas reside within databases. This structured arrangement allows clear organization, access management, and separation of workloads or business domains. A schema functions as a container that holds tables, views, functions, sequences, stages, and file formats. When users reference a table, they typically qualify it using the full three-part name: database.schema.table.

Stages are used to store or reference files, not to hold structured database tables. Virtual warehouses provide compute power for executing queries and performing DML operations but do not store data. File formats define how staged files should be interpreted (CSV, JSON, Parquet, etc.) and are unrelated to where tables physically reside.

Snowflake separates compute and storage, so while compute happens in virtual warehouses, all persistent data—including tables—is managed in Snowflake’s centralized storage layer, organized through schemas and databases. This organization ensures consistency, ease of management, and predictable access control.

==================

By default, Snowflake usesON_ERROR = ABORT_STATEMENTfor COPY INTO. This means that if a single row fails to load due to issues such as type mismatches or malformed data, Snowflake immediately stops the entire load operation. This behavior ensures data integrity by preventing partial or incomplete loads when errors occur.

Other error-handling modes must be explicitly specified: CONTINUE skips erroneous rows, SKIP_FILE skips whole files with errors, and VALIDATE is part of the validation mode feature, not a default COPY behavior.

Thus, unless explicitly changed, COPY INTO always uses ABORT_STATEMENT.

==================

Snowflake Materialized Views physically store the results of a defined query. This pre-computation significantly improves performance for repetitive or complex queries, especially those based on aggregations and joins. Snowflake automatically maintains materialized views asynchronously. They do not update in real-time, cannot be changed through DML, and are not intended for masking—dynamic masking policies serve that purpose.

====================================================

The Pruning section of the Snowsight Query Profile showshow Snowflake eliminated unnecessary micro-partitions from the scan phaseof the query. Snowflake stores data in micro-partitions and maintains metadata such as min/max values for each column within each partition. When a query includes filters (e.g., WHERE clauses), Snowflake evaluates this metadata to determine which micro-partitions cannot possibly satisfy the predicate. These partitions are skipped, meaning they are never scanned or read from storage.

This process drastically improves performance because Snowflake minimizes I/O, reduces compute usage, and shortens execution time. Partition pruning is especially impactful on large tables because only a fraction of the stored micro-partitions typically need to be accessed.

The Pruning section does not show removedrows—that happens during the filter step. It does not show removedcolumns—column pruning is handled separately by the optimizer. It also does not show removedobjectsfrom the plan. Its sole purpose is to document micro-partition elimination and scan reduction.

==================