Databases and schemas in Snowflake - Time & Space Complexity
Start learning this pattern below
Jump into concepts and practice - no test required
We want to understand how the time to list databases and schemas changes as the number of these objects grows.
How does Snowflake handle these operations when there are many databases and schemas?
Analyze the time complexity of the following operation sequence.
-- List all databases
SHOW DATABASES;
-- For each database, list all schemas
DECLARE db_cursor CURSOR FOR SELECT name FROM TABLE(RESULT_SCAN(LAST_QUERY_ID()));
FOR db_record IN db_cursor DO
LET db_name = db_record.name;
EXECUTE IMMEDIATE 'SHOW SCHEMAS IN DATABASE ' || db_name;
END FOR;
This sequence lists all databases, then for each database lists all its schemas.
Identify the API calls, resource provisioning, data transfers that repeat.
- Primary operation: The repeated call is
SHOW SCHEMAS IN DATABASEfor each database. - How many times: Once for each database found by
SHOW DATABASES.
As the number of databases grows, the number of schema listing calls grows the same way.
| Input Size (n) | Approx. Api Calls/Operations |
|---|---|
| 10 databases | 1 (SHOW DATABASES) + 10 (SHOW SCHEMAS) = 11 calls |
| 100 databases | 1 + 100 = 101 calls |
| 1000 databases | 1 + 1000 = 1001 calls |
Pattern observation: The total calls grow linearly with the number of databases.
Time Complexity: O(n)
This means the time to list all schemas grows directly in proportion to the number of databases.
[X] Wrong: "Listing schemas for all databases takes the same time no matter how many databases exist."
[OK] Correct: Each database requires a separate call to list its schemas, so more databases mean more calls and more time.
Understanding how operations scale with input size helps you design efficient database queries and scripts in real projects.
What if we changed the operation to list all schemas across all databases in a single call? How would the time complexity change?
Practice
Solution
Step 1: Understand the role of a schema
A schema is a container inside a database that holds tables and other data objects.Step 2: Differentiate schema from other components
User credentials, security settings, and virtual machines are unrelated to schemas in Snowflake.Final Answer:
To organize tables and other data objects within a database -> Option BQuick Check:
Schema = container for tables [OK]
- Confusing schemas with user accounts
- Thinking schemas manage security
- Mixing schemas with infrastructure components
sales_data in Snowflake?Solution
Step 1: Recall Snowflake schema creation syntax
The correct command to create a schema isCREATE SCHEMA schema_name;.Step 2: Identify incorrect options
Options A and B use invalid keywords. CREATE DATABASE sales_data; creates a database, not a schema.Final Answer:
CREATE SCHEMA sales_data; -> Option AQuick Check:
CREATE SCHEMA = correct syntax [OK]
- Using MAKE or NEW instead of CREATE
- Confusing CREATE SCHEMA with CREATE DATABASE
- Missing semicolon at the end
CREATE DATABASE company_db;
CREATE SCHEMA hr_schema;
USE DATABASE company_db;
USE SCHEMA hr_schema;
What is the current working database and schema?
Solution
Step 1: Analyze the commands step-by-step
CREATE DATABASE company_db;creates the database (current context unchanged).CREATE SCHEMA hr_schema;createshr_schemain the current database (which is the default database).USE DATABASE company_db;sets current database tocompany_db(schema:public).USE SCHEMA hr_schema;attempts to switch tohr_schemaschema incompany_db. Sincehr_schemawas created in the default database, this will fail unlesshr_schemaexists incompany_db. However, ifhr_schemawas created after switching tocompany_db, it would exist there.
Given the commands,CREATE SCHEMA hr_schema;was run before switching tocompany_db, sohr_schemais in the default database, notcompany_db. Therefore,USE SCHEMA hr_schema;will fail and schema remainspublic.Step 2: Determine current context
After execution: Database:company_db, Schema:public.Final Answer:
Database: company_db, Schema: public -> Option AQuick Check:
CREATE SCHEMA uses current DB context [OK]
- Mixing database and schema names
- Assuming schema changes database
- Forgetting USE commands set context
- Not USE DATABASE before CREATE SCHEMA
USE SCHEMA analytics; but get an error saying the schema does not exist. What is the most likely cause?Solution
Step 1: Understand USE SCHEMA behavior
TheUSE SCHEMAcommand switches to a schema within the current database context.Step 2: Identify cause of error
If the schema does not exist in the current database, Snowflake returns an error. Syntax is correct, and schemas can be switched. Creating a database is unrelated if one is already in use.Final Answer:
The current database does not contain a schema named analytics -> Option CQuick Check:
Schema must exist in current database [OK]
- Assuming USE SCHEMA creates schema
- Thinking syntax is wrong
- Ignoring current database context
sales_db with two schemas: domestic and international. Which sequence of commands correctly achieves this?Solution
Step 1: Create the database first
You must create the databasesales_dbbefore creating schemas inside it.Step 2: Set the database context and create schemas
UseUSE DATABASE sales_db;to set the context, then create schemasdomesticandinternationalinside it.Step 3: Verify command order
CREATE DATABASE sales_db; USE DATABASE sales_db; CREATE SCHEMA domestic; CREATE SCHEMA international; follows the correct order: create database, switch to it, then create schemas. Other options create schemas before database or misuse commands.Final Answer:
CREATE DATABASE sales_db; USE DATABASE sales_db; CREATE SCHEMA domestic; CREATE SCHEMA international; -> Option DQuick Check:
Create DB, USE DB, then CREATE SCHEMA [OK]
- Creating schemas before database
- Not switching to database before schemas
- Using USE DATABASE before creating it
