Snowflake Platform Features and Data Objects

Start from the shape of your data

Every object choice in Snowflake begins with one question: how strictly is this data shaped? Snowflake supports three forms, and each one changes what you can assume before querying.

Once the form is clear, the next decision is the table family. The documented families are Snowflake tables, Apache Iceberg tables, and hybrid tables. They differ less in what they can hold than in where the data lives and how it is accessed.

Choose the right table family

Snowflake tables store data in Snowflake-managed cloud storage and are ideal for data-warehouse workloads. They support structured and semi-structured data, and the FILE data type lets them represent unstructured data as well. This is the default choice when nothing in the requirements pushes you elsewhere.

Apache Iceberg tables keep their data and metadata files in external cloud storage managed by the customer rather than in Snowflake storage. They support structured and semi-structured data and suit existing data lakes or lakehouses that cannot or should not move into Snowflake storage. The distinguishing requirement is always about who owns the storage location.

Hybrid tables use index-based random reads and writes for low latency and high throughput. They support row locking and enforce unique and referential integrity constraints, which makes them suitable for transactional workloads. A hybrid table can work with other Snowflake tables and features in Unistore workloads that bring transactional and analytical data together.

Two scenarios show how quickly the table decides itself once you name the binding requirement.

A company has an existing data lake whose files must remain in cloud storage that the company manages, and it needs Snowflake query semantics over structured and semi-structured data. The binding requirement is customer-managed storage, so the answer is an Apache Iceberg table. A Snowflake table would move the optimized representation into Snowflake-managed storage, which conflicts with the requirement.

An order service needs low-latency random reads and writes, row locking, and enforced referential integrity while remaining usable alongside analytical Snowflake data. Here the binding requirements are indexed transactional access and constraint enforcement, so the answer is a hybrid table, which can join analytical data in a Unistore workload.

Note that a dynamic table never answers either question: it is defined by automatic refresh from a query and target freshness, not by a storage location or a locking model.

Bring the workload to the data

The reason all of this sits in one platform is stated plainly: Snowflake integrates features so teams can bring workloads to their data instead of moving data to separate systems for each task.

That principle organizes the rest of the concept into four areas you will keep meeting:

Each area has a small vocabulary. Learning which word belongs to which area is most of the work, because a familiar term used in the wrong area is the easiest mistake to make.

Pick the ingestion path that matches the trigger

Three loading options differ by what starts the load, not by how much data they move.

For file-based ingestion, COPY INTO <table> loads files into a table, while Snowpipe loads files when they become available in a stage. Snowpipe Streaming loads row-level data continuously with low latency through Snowflake SDKs or a REST API rather than from files.

So a pipeline that must react to files as they appear in a stage, without needing direct row-level SDK ingestion, is describing Snowpipe: it sits between the manual file load and the continuous row stream.

Know which tool performs the transformation

Transformation has three distinct mechanisms, and each one owns a different part of the job.

• Dynamic tables refresh automatically according to a target freshness and a transformation query. You declare the result you want and how fresh it must be.
• Streams capture changes to base objects. A stream is a record of what changed, not a processor.
• Tasks define work that can perform transformations. A task is the unit that actually runs.
• Snowpark supports transformations in languages such as Python, Java, and Scala, for logic that outgrows SQL.

The stream-and-task split is the one most often confused. Streams observe; tasks act. Neither enforces constraints, manages external files, defines business metrics, deploys containers, or builds interfaces — those belong to hybrid tables, Iceberg tables, semantic views, Snowpark Container Services, and Streamlit respectively.

Analyze with the right SQL construct

For analytics, the distinction between the function types is about how many rows come back and in what context.

An aggregate collapses; a window keeps every row and adds a calculation computed across its partition. That is why a running total is a window operation: you still want each row, plus the total so far.

Semantic views sit one level above both. Instead of expressing a metric again in every query, the definitions of metrics, entities, and their relationships live in the database.

Separate the AI suites

Two AI suites answer two different questions.

Snowflake Cortex provides AI features that use large language models for unstructured data, freeform questions, and assistance such as summaries or translations. Reach for it when the input is text or another unstructured form and the output is language.

Snowflake ML provides a unified environment for building models, and ML functions provide automated predictions and insights. Reach for it when you are training or scoring against your own data rather than asking a language model a question.

Build and share without moving the data

The application and collaboration features complete the picture: they let logic and access travel to the data instead of the reverse.

The Native App Framework is the one to recognize by its packaging: it is data plus business logic, delivered to another Snowflake account as an application.

Collaboration deserves one more pass, because the three sharing features are close cousins with different limits.

• Secure Data Sharing decides which objects another account can see.
• Listings decide how data and other information are provided or accessed.
• Data Clean Rooms decide which analyses a consumer may run against shared data, so the consumer can derive insight without unrestricted analytical access.

That last boundary is the one exam scenarios test. A clean room is not about relocating data into consumer-managed storage, not about row locks, and not about ingestion through a REST API; it is a control on the permitted analyses.

Key takeaways

• Match the table to the requirement: Snowflake tables for Snowflake-managed warehouse storage, Iceberg tables for customer-managed external lake storage, and hybrid tables for indexed transactional access with row locking and enforced constraints.
• Distinguish the three loading paths: COPY INTO <table> for command-driven file loading, Snowpipe for loading files as they arrive in a stage, and Snowpipe Streaming for continuous row-level ingestion through SDKs or a REST API.
• Keep transformation roles apart: dynamic tables refresh from a query and target freshness, streams capture base-object changes, tasks define the work, and Snowpark handles Python, Java, and Scala logic.
• Keep analytics roles apart: aggregates collapse rows into one value, window functions calculate within partitions, CTEs aid readability and reuse, and semantic views store business metrics and relationships.
• Know the collaboration boundary: Secure Data Sharing shares selected objects, Listings provide or access data and other information, and Data Clean Rooms restrict which analyses consumers can run against shared data.