Skip to main content
πŸ“–

Key Terms β€” Databases, Schemas & Tables

DB

Database

A top-level container in Snowflake that holds one or more schemas. Databases provide logical separation and namespace isolation for all objects within them.

SCH

Schema

A second-level container within a database that groups related tables, views, procedures, and other objects. Every database automatically includes INFORMATION_SCHEMA and PUBLIC schemas.

PT

Permanent Table

The default table type in Snowflake. Permanent tables persist until explicitly dropped and benefit from full Time Travel (up to 90 days) and Fail-safe (7 days) protection.

TT

Transient Table

A table type that persists across sessions but has no Fail-safe period and a maximum of 1 day of Time Travel. Designed for staging and ETL workloads where cost savings outweigh recovery needs.

TEMP

Temporary Table

A session-scoped table that is automatically dropped when the session ends. Not visible to other sessions. Has no Fail-safe and a maximum of 1 day of Time Travel.

ET

External Table

A read-only table that references data stored in an external stage (S3, Azure Blob, or GCS). Only metadata is stored in Snowflake; no data is copied into Snowflake storage.

VAR

VARIANT

A semi-structured data type that can store JSON, XML, Avro, ORC, and Parquet data. Supports path-based access using colon (:) notation and type casting with double-colon (::) notation.

INFO_SCH

INFORMATION_SCHEMA

An auto-created schema within every Snowflake database that contains views exposing metadata about objects within that database. Query latency is near real-time but limited to the current database.

ACC_USE

ACCOUNT_USAGE

A schema in the shared SNOWFLAKE database that provides account-wide metadata views. Has a latency of 45 minutes to 3 hours but includes historical and deleted objects.

CON

Constraint

Logical rules (NOT NULL, UNIQUE, PRIMARY KEY, FOREIGN KEY) that can be defined on Snowflake tables. Constraints are informational only and are NOT enforced by Snowflake's query engine.

Why This Topic Matters for the Exam

Understanding Snowflake’s object hierarchy is foundational to the SnowPro Core (COF-C02) exam. Every question about storage, data organisation, Time Travel, and data lifecycle ultimately traces back to how databases, schemas, and tables are structured. The exam heavily tests the differences between table types β€” particularly where Transient and Temporary tables are appropriate versus Permanent tables β€” and candidates frequently lose marks by confusing Fail-safe availability across these types.

This module will walk you through the complete database object model from the top-level database container down to column-level data types, including the VARIANT semi-structured type that underpins Snowflake’s flexible schema capabilities.

🎯Exam Weight: High Priority

The Snowflake object hierarchy (databases, schemas, tables) appears across multiple exam domains. Expect 8–12 questions touching on table types, DDL syntax, INFORMATION_SCHEMA vs ACCOUNT_USAGE, and constraint behaviour. This is one of the highest-value topics on the COF-C02 exam.


The Snowflake Object Hierarchy

Snowflake organises all data objects in a strict three-level hierarchy: Database > Schema > Table/View/Procedure. This hierarchy enforces namespace isolation and enables granular access control at each level.

Snowflake Object Hierarchy

A tree diagram showing the complete Snowflake object hierarchy. At the top is the Snowflake Account, which contains one or more Databases. Each Database contains two auto-created schemas (INFORMATION_SCHEMA and PUBLIC) plus any user-created schemas. Within each Schema live Tables (Permanent, Transient, Temporary, External), Views, Sequences, File Formats, Stages, Stored Procedures, Functions, Tasks, and Streams. Arrows indicate containment relationships flowing top-down. The INFORMATION_SCHEMA schema is highlighted in blue to show it is system-managed and read-only.

Snowflake object hierarchy from Account down to Tables and Views

Every object in Snowflake is addressed by its fully qualified name using dot notation:

database_name.schema_name.object_name

For example: PROD_DB.ANALYTICS.CUSTOMER_ORDERS


Databases

A database in Snowflake is the highest-level logical container for data. It groups related schemas together and provides the top-level namespace for all objects.

Creating and Managing Databases

Database DDL β€” CREATE, ALTER, DROP, SHOW
1-- Create a standard permanent database
2CREATE DATABASE prod_db
3DATA_RETENTION_TIME_IN_DAYS = 14
4COMMENT = 'Production analytics database';
5
6-- Create a transient database (no Fail-safe, max 1 day Time Travel)
7-- All schemas and tables within inherit the transient property
8CREATE TRANSIENT DATABASE staging_db
9DATA_RETENTION_TIME_IN_DAYS = 1
10COMMENT = 'ETL staging area β€” transient, no Fail-safe';
11
12-- Switch the active database for the current session
13USE DATABASE prod_db;
14
15-- Rename a database
16ALTER DATABASE prod_db RENAME TO production_db;
17
18-- Change Time Travel retention on an existing database
19ALTER DATABASE production_db
20SET DATA_RETENTION_TIME_IN_DAYS = 30;
21
22-- Show all databases accessible to the current role
23SHOW DATABASES;
24
25-- Show databases matching a pattern
26SHOW DATABASES LIKE 'prod%';
27
28-- Drop a database (irreversible β€” Time Travel window starts here)
29DROP DATABASE old_db;
30
31-- Undrop within Time Travel window
32UNDROP DATABASE old_db;
πŸ”‘Transient Database Inheritance

When you create a TRANSIENT DATABASE, all schemas and tables created within that database automatically inherit the transient property. You cannot create a permanent table inside a transient database. This is a commonly tested exam behaviour.

Key Database Properties

PropertyDefaultDescription
DATA_RETENTION_TIME_IN_DAYS1 (Standard), up to 90 (Enterprise)Controls Time Travel window
TRANSIENTFALSERemoves Fail-safe; max 1-day Time Travel
COMMENTNULLDescriptive text for the database

Schemas

A schema is a logical grouping within a database. It holds tables, views, stages, file formats, sequences, procedures, functions, tasks, and streams.

Auto-Created Schemas

Every database automatically contains two schemas that you cannot drop:

  1. INFORMATION_SCHEMA β€” Contains metadata views about objects in the current database
  2. PUBLIC β€” The default schema where objects are created when no schema is specified
⚠️You Cannot Drop INFORMATION_SCHEMA

Attempting to DROP or ALTER the INFORMATION_SCHEMA schema will result in an error. It is a system-managed, read-only schema. This is a common trick question on the exam.

Creating and Managing Schemas

Schema DDL β€” CREATE, ALTER, USE
1-- Create a standard schema
2CREATE SCHEMA prod_db.analytics
3DATA_RETENTION_TIME_IN_DAYS = 14
4COMMENT = 'Analytics reporting schema';
5
6-- Create a transient schema (no Fail-safe)
7CREATE TRANSIENT SCHEMA prod_db.staging
8DATA_RETENTION_TIME_IN_DAYS = 1;
9
10-- Switch active schema for the session
11USE SCHEMA prod_db.analytics;
12
13-- Alternatively, use the two-part notation
14USE prod_db.analytics;
15
16-- Rename a schema
17ALTER SCHEMA analytics RENAME TO reporting;
18
19-- Show all schemas in the current database
20SHOW SCHEMAS;
21
22-- Show schemas in a specific database
23SHOW SCHEMAS IN DATABASE prod_db;
24
25-- Drop and undrop schema
26DROP SCHEMA old_schema;
27UNDROP SCHEMA old_schema;
πŸ’‘Schema Data Retention Inheritance

If a schema’s DATA_RETENTION_TIME_IN_DAYS is not explicitly set, it inherits from the parent database. Similarly, if a table’s retention is not set, it inherits from the schema. Setting retention at the database level provides a convenient default for all objects below it.


Table Types β€” The Exam’s Most Tested Topic

Snowflake has four distinct table types, each with different persistence, Time Travel, and Fail-safe characteristics. Mastering these differences is critical for the COF-C02 exam.

Snowflake Table Types Comparison

A side-by-side comparison matrix of Snowflake's four table types. Columns represent: Permanent Table, Transient Table, Temporary Table, External Table. Rows show: Persistence (Permanent: until dropped; Transient: until dropped; Temporary: session only; External: read-only reference), Time Travel (Permanent: 0-90 days; Transient: 0-1 day; Temporary: 0-1 day; External: none), Fail-safe (Permanent: 7 days; Transient: none; Temporary: none; External: none), Cross-session visibility (Permanent: yes; Transient: yes; Temporary: no, private to session; External: yes), Storage cost (Permanent: highest; Transient: lower, no fail-safe overhead; Temporary: lowest; External: metadata only). The Temporary column is highlighted in yellow with a note 'Session-scoped only'. The External column shows a cloud icon representing data residing in S3/Azure/GCS.

Comparison matrix of Permanent, Transient, Temporary, and External table types

1. Permanent Tables

The default table type. Created with CREATE TABLE unless another type is specified.

  • Full Time Travel: 0–90 days (Standard edition: max 1 day; Enterprise+: up to 90 days)
  • Full Fail-safe: always 7 days beyond Time Travel window
  • Persist until explicitly DROPped
  • Visible to all roles with appropriate privileges

2. Transient Tables

Created with CREATE TRANSIENT TABLE. Designed for data that does not require Fail-safe protection.

  • No Fail-safe period (0 days)
  • Time Travel: 0–1 day maximum
  • Persist across sessions until explicitly dropped
  • Ideal for: staging tables, ETL intermediates, scratch tables that are rebuilt regularly

3. Temporary Tables

Created with CREATE TEMPORARY TABLE (or CREATE TEMP TABLE).

  • Session-scoped: automatically dropped when the session ends
  • Not visible to other sessions (private to the creating session)
  • No Fail-safe period (0 days)
  • Time Travel: 0–1 day maximum
  • If a temporary table has the same name as a permanent/transient table in the same schema, the temporary table takes precedence within that session

4. External Tables

Created with CREATE EXTERNAL TABLE. The data resides in an external stage (S3, Azure Blob Storage, or GCS).

  • Read-only β€” you cannot INSERT, UPDATE, or DELETE data via an external table
  • Only metadata (column definitions, file locations) is stored in Snowflake
  • No Time Travel, No Fail-safe
  • Supports partitioning via partition columns
  • Requires an external stage to be defined first
Creating All Four Table Types
1-- 1. Permanent table (default)
2CREATE TABLE prod_db.analytics.customers (
3customer_id NUMBER(10, 0) NOT NULL,
4email VARCHAR(255) NOT NULL,
5created_at TIMESTAMP_NTZ DEFAULT CURRENT_TIMESTAMP(),
6is_active BOOLEAN DEFAULT TRUE
7);
8
9-- 2. Transient table β€” no Fail-safe, max 1-day Time Travel
10CREATE TRANSIENT TABLE staging.raw_customer_events (
11event_id VARCHAR(36),
12event_type VARCHAR(100),
13payload VARIANT,
14loaded_at TIMESTAMP_LTZ DEFAULT CURRENT_TIMESTAMP()
15)
16DATA_RETENTION_TIME_IN_DAYS = 1;
17
18-- 3. Temporary table β€” dropped when session ends
19CREATE TEMPORARY TABLE temp_dedup_results (
20customer_id NUMBER,
21row_num NUMBER
22);
23
24-- 4. External table β€” data lives in S3
25CREATE EXTERNAL TABLE ext_raw_logs (
26log_date DATE AS (TO_DATE($1:log_date::STRING)),
27log_level VARCHAR AS ($1:level::STRING),
28message VARCHAR AS ($1:message::STRING)
29)
30PARTITION BY (log_date)
31LOCATION = @my_s3_stage/logs/
32FILE_FORMAT = (TYPE = 'JSON')
33AUTO_REFRESH = TRUE;

Transient vs Temporary Tables

Feature
Transient Table
Temporary Table
Persistence
βœ“Until explicitly dropped
Auto-dropped when session ends
Cross-session visibility
Yes β€” visible to all with access
No β€” private to creating session
Time Travel maximum
1 day
1 day
Fail-safe period
None (0 days)
None (0 days)
Best use case
Staging, ETL intermediates, shared scratch
Session-level deduplication, temp calculations
Name collision behaviour
Normal β€” errors if name exists
Shadows permanent/transient table of same name within session
Storage cost
Lower than permanent (no fail-safe)
βœ“Lowest β€” discarded at session end
DDL keyword
CREATE TRANSIENT TABLE
CREATE TEMPORARY TABLE or CREATE TEMP TABLE

Table DDL Operations

Advanced Table DDL β€” CTAS, LIKE, ALTER
1-- CREATE TABLE AS SELECT (CTAS) β€” creates and populates in one step
2CREATE TABLE analytics.customer_summary AS
3SELECT
4customer_id,
5COUNT(*) AS order_count,
6SUM(amount) AS total_spend,
7MAX(order_date) AS last_order_date
8FROM analytics.orders
9GROUP BY customer_id;
10
11-- CREATE TABLE LIKE β€” copies structure only, no data
12CREATE TABLE analytics.customer_summary_backup
13LIKE analytics.customer_summary;
14
15-- CREATE OR REPLACE TABLE β€” atomically drops and recreates
16-- WARNING: drops all data and resets Time Travel history
17CREATE OR REPLACE TABLE analytics.staging_load (
18id NUMBER AUTOINCREMENT,
19raw_data VARIANT
20);
21
22-- ALTER TABLE β€” add, drop, rename columns
23ALTER TABLE analytics.customers
24ADD COLUMN phone_number VARCHAR(20);
25
26ALTER TABLE analytics.customers
27DROP COLUMN phone_number;
28
29ALTER TABLE analytics.customers
30RENAME COLUMN email TO email_address;
31
32-- Change Time Travel retention at table level
33ALTER TABLE analytics.customers
34SET DATA_RETENTION_TIME_IN_DAYS = 30;
35
36-- SHOW commands for tables
37SHOW TABLES;
38SHOW TABLES IN SCHEMA analytics;
39SHOW TABLES LIKE 'customer%' IN DATABASE prod_db;
40SHOW COLUMNS IN TABLE analytics.customers;
⚠️CREATE OR REPLACE Resets Time Travel

Using CREATE OR REPLACE TABLE drops the existing table and creates a new one. This resets the Time Travel history β€” you cannot use AT (BEFORE) to query data from before the replacement. Use TRUNCATE TABLE instead if you need to preserve the table’s Time Travel history.


Snowflake Data Types

Snowflake Data Type Categories

A categorised diagram of Snowflake data types organised into five groups. Group 1 (Numeric): NUMBER/DECIMAL/NUMERIC (fixed-point), INT/INTEGER/BIGINT/SMALLINT/TINYINT (integer aliases mapped to NUMBER), FLOAT/FLOAT4/FLOAT8/DOUBLE (64-bit floating point), REAL (alias for FLOAT). Group 2 (String): VARCHAR/STRING/TEXT/CHAR/CHARACTER (all map to VARCHAR, max 16MB), BINARY/VARBINARY (raw bytes). Group 3 (Date and Time): DATE (no time component), TIME (no date component), TIMESTAMP_NTZ (no timezone, stored as-is), TIMESTAMP_LTZ (local timezone, stored in UTC), TIMESTAMP_TZ (with timezone offset stored). Group 4 (Boolean): BOOLEAN (TRUE/FALSE/NULL). Group 5 (Semi-Structured): VARIANT (up to 16MB, stores JSON/XML/Avro/Parquet), ARRAY (ordered list of VARIANT values), OBJECT (key-value map of VARIANT values). Group 6 (Geospatial): GEOGRAPHY (earth-curvature-aware), GEOMETRY (flat-plane calculations). Each group has a distinct colour and icon in the diagram.

Categorised diagram of all Snowflake data types

Key Data Types for the Exam

Data Type Usage Examples
1-- Numeric types
2CREATE TABLE type_examples (
3-- NUMBER(precision, scale) β€” alias: DECIMAL, NUMERIC
4price NUMBER(10, 2), -- up to 9,999,999.99
5quantity NUMBER(8, 0), -- integer stored as NUMBER
6rate FLOAT, -- 64-bit double precision
7
8-- String types β€” all aliases for VARCHAR internally
9name VARCHAR(255), -- explicit length
10description STRING, -- alias, max 16MB
11notes TEXT, -- alias, max 16MB
12
13-- Boolean
14is_active BOOLEAN, -- TRUE / FALSE / NULL
15
16-- Date and time
17birth_date DATE, -- YYYY-MM-DD
18login_time TIME, -- HH:MI:SS.FFFFFFFFF
19created_utc TIMESTAMP_NTZ, -- no timezone stored
20event_local TIMESTAMP_LTZ, -- stores in UTC, displays in session TZ
21recorded_at TIMESTAMP_TZ, -- stores offset with value
22
23-- Semi-structured
24raw_json VARIANT, -- any JSON, XML, Avro, Parquet (max 16MB)
25tags ARRAY, -- ordered list of VARIANT values
26attributes OBJECT -- key-value pairs
27);

The VARIANT Type β€” Semi-Structured Data

VARIANT is one of Snowflake’s most powerful features, enabling schema-on-read for semi-structured data. It is a common exam topic.

Working with VARIANT Data β€” Path Access and Casting
1-- Insert JSON into a VARIANT column
2INSERT INTO staging.raw_events (payload)
3SELECT PARSE_JSON('{
4"user_id": 12345,
5"event": "purchase",
6"items": [
7 {"sku": "A001", "qty": 2, "price": 29.99},
8 {"sku": "B002", "qty": 1, "price": 149.00}
9],
10"metadata": {
11 "session_id": "abc-123",
12 "ip_address": "192.168.1.1"
13}
14}');
15
16-- Path access using colon (:) notation
17SELECT
18payload:user_id AS user_id, -- returns VARIANT
19payload:event AS event_type,
20payload:metadata:session_id AS session_id, -- nested path
21payload:items[0]:sku AS first_sku -- array index
22FROM staging.raw_events;
23
24-- Type casting with double-colon (::) β€” explicit CAST
25SELECT
26payload:user_id::NUMBER AS user_id_num, -- VARIANT -> NUMBER
27payload:event::VARCHAR AS event_str, -- VARIANT -> STRING
28payload:metadata:session_id::STRING AS session_str
29FROM staging.raw_events;
30
31-- Flatten arrays β€” LATERAL FLATTEN expands array into rows
32SELECT
33f.value:sku::VARCHAR AS sku,
34f.value:qty::NUMBER AS quantity,
35f.value:price::FLOAT AS price
36FROM staging.raw_events,
37 LATERAL FLATTEN(INPUT => payload:items) f;
38
39-- Check if a path exists
40SELECT
41payload:user_id IS NOT NULL AS has_user_id
42FROM staging.raw_events;
🎯VARIANT Path Access Syntax

The exam tests VARIANT syntax carefully. Remember: single colon (:) accesses a nested path and returns a VARIANT; double colon (::) casts the VARIANT to a specific type. For arrays, use square bracket notation with a zero-based index: payload:items[0]:sku::VARCHAR.


INFORMATION_SCHEMA vs ACCOUNT_USAGE

These two metadata sources are heavily tested because they serve different purposes and have different latency and scope characteristics.

INFORMATION_SCHEMA vs ACCOUNT_USAGE

Feature
INFORMATION_SCHEMA
SNOWFLAKE.ACCOUNT_USAGE
Location
Every database (database.INFORMATION_SCHEMA)
SNOWFLAKE shared database (SNOWFLAKE.ACCOUNT_USAGE)
Scope
Current database only
βœ“Entire Snowflake account
Query latency
βœ“Near real-time (seconds)
45 minutes to 3 hours
Deleted objects
No β€” only shows current objects
βœ“Yes β€” includes dropped/deleted objects
Historical data retention
Limited (7 days for some views)
βœ“Up to 1 year
Access requirement
βœ“Any role with object access
Requires ACCOUNTADMIN or SNOWFLAKE database grant
Typical use case
Real-time object discovery, column metadata
Cost analysis, security audits, usage trends
Key views
TABLES, COLUMNS, VIEWS, LOAD_HISTORY, TABLE_STORAGE_METRICS
QUERY_HISTORY, WAREHOUSE_METERING_HISTORY, LOGIN_HISTORY, STORAGE_USAGE
Querying INFORMATION_SCHEMA and ACCOUNT_USAGE
1-- INFORMATION_SCHEMA: tables in current database
2SELECT
3table_name,
4table_type,
5row_count,
6bytes,
7retention_time
8FROM information_schema.tables
9WHERE table_schema = 'ANALYTICS'
10ORDER BY bytes DESC;
11
12-- INFORMATION_SCHEMA: column metadata
13SELECT
14table_name,
15column_name,
16data_type,
17character_maximum_length,
18is_nullable
19FROM information_schema.columns
20WHERE table_schema = 'ANALYTICS'
21AND table_name = 'CUSTOMERS';
22
23-- INFORMATION_SCHEMA: load history (last 14 days)
24SELECT
25table_name,
26last_load_time,
27row_count,
28error_count
29FROM information_schema.load_history
30WHERE schema_name = 'ANALYTICS'
31ORDER BY last_load_time DESC;
32
33-- ACCOUNT_USAGE: query history across entire account (ACCOUNTADMIN required)
34SELECT
35query_id,
36user_name,
37warehouse_name,
38execution_time / 1000 AS execution_seconds,
39bytes_scanned,
40query_text
41FROM snowflake.account_usage.query_history
42WHERE start_time >= DATEADD('day', -7, CURRENT_TIMESTAMP())
43AND execution_status = 'SUCCESS'
44ORDER BY execution_time DESC
45LIMIT 100;
46
47-- ACCOUNT_USAGE: storage usage over time
48SELECT
49usage_date,
50database_name,
51average_database_bytes / POWER(1024, 3) AS avg_gb
52FROM snowflake.account_usage.database_storage_usage_history
53WHERE usage_date >= DATEADD('month', -1, CURRENT_DATE())
54ORDER BY usage_date DESC;
πŸ’‘Use INFORMATION_SCHEMA for Real-Time Checks

When you need to verify that a table exists or check column definitions right now, use INFORMATION_SCHEMA. When you need to audit what happened over the past week or month across all users and warehouses, use SNOWFLAKE.ACCOUNT_USAGE.


SHOW Commands

SHOW commands retrieve metadata from Snowflake’s internal catalogue without needing to query INFORMATION_SCHEMA.

SHOW Command Reference
1-- Show all databases in the account
2SHOW DATABASES;
3
4-- Show databases matching a pattern
5SHOW DATABASES LIKE 'prod%';
6
7-- Show schemas in the current database
8SHOW SCHEMAS;
9
10-- Show schemas in a specific database
11SHOW SCHEMAS IN DATABASE prod_db;
12
13-- Show all tables in the current schema
14SHOW TABLES;
15
16-- Show tables in a specific schema
17SHOW TABLES IN SCHEMA prod_db.analytics;
18
19-- Show tables matching a pattern
20SHOW TABLES LIKE 'customer%';
21
22-- Show column definitions for a table
23SHOW COLUMNS IN TABLE analytics.customers;
24
25-- Show views in the current schema
26SHOW VIEWS;
27
28-- Show stages accessible to current role
29SHOW STAGES;
30
31-- Show file formats
32SHOW FILE FORMATS;
33
34-- Access SHOW results via result_scan
35SHOW TABLES IN SCHEMA analytics;
36SELECT "name", "kind", "rows", "bytes"
37FROM TABLE(RESULT_SCAN(LAST_QUERY_ID()));

Constraints in Snowflake

Snowflake supports standard SQL constraint types, but with a critically important caveat: constraints are informational only and are NOT enforced.

🎯Constraints Are NOT Enforced β€” Critical Exam Fact

This is one of the most frequently tested facts about Snowflake tables. You CAN define PRIMARY KEY, FOREIGN KEY, UNIQUE, and NOT NULL constraints, but Snowflake does NOT enforce them during INSERT, UPDATE, or MERGE operations. They exist purely as metadata for query optimisers and ETL tools that read schema information.

Defining Constraints (Informational Only)
1-- Constraints can be defined inline
2CREATE TABLE analytics.orders (
3order_id NUMBER NOT NULL, -- informational only
4customer_id NUMBER NOT NULL,
5order_date DATE NOT NULL,
6total_amount NUMBER(12, 2),
7status VARCHAR(20),
8
9-- Primary key β€” informational, not enforced
10CONSTRAINT pk_orders PRIMARY KEY (order_id),
11
12-- Foreign key β€” informational, not enforced
13CONSTRAINT fk_orders_customer
14 FOREIGN KEY (customer_id)
15 REFERENCES analytics.customers (customer_id)
16);
17
18-- Add constraint to existing table
19ALTER TABLE analytics.orders
20ADD CONSTRAINT uq_order_customer UNIQUE (order_id, customer_id);
21
22-- Show constraints on a table
23SHOW PRIMARY KEYS IN TABLE analytics.orders;
24SHOW IMPORTED KEYS IN TABLE analytics.orders;
25SHOW UNIQUE KEYS IN TABLE analytics.orders;
26
27-- IMPORTANT: This INSERT succeeds even though it violates NOT NULL
28-- Snowflake does NOT enforce constraints
29INSERT INTO analytics.orders (order_id, customer_id, order_date)
30VALUES (NULL, NULL, NULL); -- Will succeed! Constraints not enforced.

Step-by-Step: Building a Layered Database Architecture

Setting Up a Medallion Architecture in Snowflake

1
Create the Databases

Establish separate databases for each layer of your data architecture. Use a transient database for the bronze (raw) layer since that data can be re-loaded from source systems.

SQL
-- Bronze: raw ingestion β€” transient to save costs
CREATE TRANSIENT DATABASE bronze_db
DATA_RETENTION_TIME_IN_DAYS = 1
COMMENT = 'Raw source data β€” reloadable from source';

-- Silver: cleansed and conformed
CREATE DATABASE silver_db
DATA_RETENTION_TIME_IN_DAYS = 14
COMMENT = 'Cleansed and validated data';

-- Gold: business-ready aggregates
CREATE DATABASE gold_db
DATA_RETENTION_TIME_IN_DAYS = 30
COMMENT = 'Business-ready reporting layer';
πŸ’‘Using a transient database for raw data eliminates the 7-day Fail-safe cost since you can always reload from source. This is a common cost-optimisation pattern.
2
Create the Schemas

Organise each database with meaningful schemas. The silver and gold databases use permanent schemas that inherit the database's Time Travel retention.

SQL
-- Bronze schemas β€” inherit transient from database
USE DATABASE bronze_db;
CREATE SCHEMA raw_crm;
CREATE SCHEMA raw_erp;
CREATE SCHEMA raw_clickstream;

-- Silver schemas
USE DATABASE silver_db;
CREATE SCHEMA conformed;
CREATE SCHEMA staging;

-- Gold schemas
USE DATABASE gold_db;
CREATE SCHEMA finance;
CREATE SCHEMA marketing;
CREATE SCHEMA operations;
3
Create the Tables

Use the appropriate table type for each layer. Bronze uses transient tables, silver and gold use permanent tables.

SQL
-- Bronze: transient staging table
CREATE TRANSIENT TABLE bronze_db.raw_crm.accounts (
_load_id        VARCHAR(36) DEFAULT UUID_STRING(),
_loaded_at      TIMESTAMP_LTZ DEFAULT CURRENT_TIMESTAMP(),
_file_name      VARCHAR(500),
raw_data        VARIANT
)
DATA_RETENTION_TIME_IN_DAYS = 1;

-- Silver: permanent table with proper types
CREATE TABLE silver_db.conformed.customers (
customer_key    NUMBER AUTOINCREMENT PRIMARY KEY,
source_id       VARCHAR(100) NOT NULL,
full_name       VARCHAR(255),
email           VARCHAR(255),
created_date    DATE,
updated_at      TIMESTAMP_NTZ
)
DATA_RETENTION_TIME_IN_DAYS = 14;

-- Gold: permanent aggregate table
CREATE TABLE gold_db.marketing.customer_ltv AS
SELECT
customer_key,
SUM(order_total) AS lifetime_value,
COUNT(*)         AS order_count,
MIN(order_date)  AS first_order_date,
MAX(order_date)  AS last_order_date
FROM silver_db.conformed.orders
GROUP BY customer_key;
πŸ’‘The CTAS (CREATE TABLE AS SELECT) pattern in the gold layer is extremely efficient β€” Snowflake creates the table and loads data in a single optimised operation.
4
Verify with INFORMATION_SCHEMA

Query INFORMATION_SCHEMA to verify the table types, retention settings, and row counts across your new architecture.

SQL
-- Verify table types and retention across all databases
SELECT
t.table_catalog,
t.table_schema,
t.table_name,
t.table_type,
t.retention_time,
t.row_count,
ROUND(t.bytes / POWER(1024, 3), 4) AS size_gb
FROM gold_db.information_schema.tables t
WHERE table_type NOT IN ('VIEW')
ORDER BY table_catalog, table_schema, table_name;

-- Check that CTAS populated the gold table
SELECT COUNT(*) AS row_count
FROM gold_db.marketing.customer_ltv;

Quick Reference Cheat Sheet

πŸ“‹
Quick Reference

Databases, Schemas & Tables β€” COF-C02 Cheat Sheet

T
Table Type Summary
CREATE TABLE
Permanentβ€” Full Time Travel + 7-day Fail-safe
CREATE TRANSIENT TABLE
Transientβ€” No Fail-safe, max 1-day Time Travel
CREATE TEMPORARY TABLE
Temporaryβ€” Session-scoped, no Fail-safe, max 1-day Time Travel
CREATE EXTERNAL TABLE
Externalβ€” Read-only, no Time Travel, no Fail-safe
D
Key DDL Patterns
CTAS
CREATE TABLE t AS SELECT ...β€” Creates and populates in one step
LIKE
CREATE TABLE t LIKE source_tβ€” Copies structure only, no data
OR REPLACE
CREATE OR REPLACE TABLE t (...)β€” Resets Time Travel history!
Add column
ALTER TABLE t ADD COLUMN c TYPEβ€” Non-destructive
Rename column
ALTER TABLE t RENAME COLUMN old TO newβ€” Non-destructive
J
VARIANT Access Syntax
Path access
col:keyβ€” Returns VARIANT
Nested path
col:key1:key2β€” Dot-path traversal
Array index
col:array[0]β€” Zero-based index
Type cast
col:key::VARCHARβ€” Cast VARIANT to type
Flatten array
LATERAL FLATTEN(INPUT => col:arr) fβ€” Expands to rows
M
Metadata Sources
INFORMATION_SCHEMA
Current DB, near real-timeβ€” TABLES, COLUMNS, LOAD_HISTORY
ACCOUNT_USAGE
All DBs, 45min-3hr latencyβ€” QUERY_HISTORY, METERING_HISTORY
SHOW TABLES
Fast catalogue lookupβ€” Use RESULT_SCAN() to query output
C
Constraints Behaviour
NOT NULL
Informational onlyβ€” NOT enforced on INSERT/UPDATE
PRIMARY KEY
Informational onlyβ€” NOT enforced, used by optimiser
FOREIGN KEY
Informational onlyβ€” NOT enforced by Snowflake
UNIQUE
Informational onlyβ€” NOT enforced by Snowflake

Practice Quiz

Databases & Tables

A developer creates a TEMPORARY TABLE named CUSTOMER_STAGING in schema ANALYTICS, where a PERMANENT TABLE with the same name already exists. What happens when the developer queries CUSTOMER_STAGING within the same session?

Databases & Tables

Which of the following statements about Snowflake constraints is CORRECT?

Databases & Tables

A data engineer needs to store 90 days of Time Travel history for a critical customer table. Which Snowflake edition and table type must be used?


Flashcard Exam Prep

Table Types
QUESTION

What is the maximum Time Travel retention period for a Transient table?

Click to reveal answer
ANSWER

1 day (DATA_RETENTION_TIME_IN_DAYS = 1). Transient tables do not have a Fail-safe period. They persist across sessions until dropped but sacrifice data protection for lower storage costs.

Click to see question
Table Types
QUESTION

What happens to a Temporary table when the Snowflake session ends?

Click to reveal answer
ANSWER

The Temporary table is automatically dropped. Temporary tables are session-scoped β€” they are private to the creating session, invisible to all other sessions, and are automatically destroyed when the session terminates.

Click to see question
VARIANT
QUESTION

What does the :: (double colon) operator do when used with a VARIANT column?

Click to reveal answer
ANSWER

The :: operator performs an explicit type cast, converting a VARIANT value to a specific Snowflake data type. For example, payload:user_id::NUMBER converts the VARIANT value at the 'user_id' path to a NUMBER type. Without ::, path access returns VARIANT.

Click to see question
Metadata
QUESTION

What is the key difference between INFORMATION_SCHEMA and SNOWFLAKE.ACCOUNT_USAGE?

Click to reveal answer
ANSWER

INFORMATION_SCHEMA is per-database, near real-time, but only shows current objects in that database. SNOWFLAKE.ACCOUNT_USAGE covers the entire account, retains up to 1 year of history including dropped objects, but has a latency of 45 minutes to 3 hours.

Click to see question
Constraints
QUESTION

Are PRIMARY KEY constraints enforced in Snowflake?

Click to reveal answer
ANSWER

No. Snowflake constraints (NOT NULL, UNIQUE, PRIMARY KEY, FOREIGN KEY) are informational only and are NOT enforced by the query engine. You can insert duplicate values or NULL values into constrained columns without error.

Click to see question
DDL
QUESTION

What is the difference between CREATE TABLE LIKE and CREATE TABLE AS SELECT (CTAS)?

Click to reveal answer
ANSWER

CREATE TABLE LIKE copies only the table structure (columns and data types) without any data β€” it creates an empty table. CREATE TABLE AS SELECT (CTAS) creates a new table AND populates it with the result of the SELECT query in a single atomic operation.

Click to see question

Additional Resources


Next Steps

Reinforce what you just read

Study the All flashcards with spaced repetition to lock it in.

Study flashcards β†’