How dbt's core materialization types differ

Materializations control how dbt turns a model's SELECT statement into objects in your warehouse, balancing build time, storage cost, and query performance. dbt supports four core materializations—view, table, incremental, and ephemeral—configurable per model, folder, or project via the materialized config. Choosing the right one is central to optimizing model performance and warehouse spend.

Must-know

• Views are the default materialization; dbt wraps the SELECT in a CREATE VIEW statement, so no data is stored but every query re-runs the full logic against the underlying tables.
• Table materialization runs a CREATE TABLE AS (or equivalent) each run, fully rebuilding the table from scratch, which is simple and fast to query but can be slow and costly to build for large datasets.
• Incremental materialization builds a table once, then on subsequent runs only inserts/updates new or changed rows using a configurable unique_key and is_incremental() macro logic, dramatically reducing processing time for large, append-heavy datasets.
• Ephemeral models are not built as database objects at all; dbt inlines their SQL as a CTE into downstream models, useful for lightweight reusable logic but they cannot be queried directly and add complexity to compiled SQL if overused.
• Incremental models require careful handling of schema changes and late-arriving/updated data (via strategies like merge, delete+insert, or append) and often need a full-refresh run to rebuild correctly when logic changes.
• Materialization choice should be driven by downstream query patterns and rebuild cost: staging/light-transform models often use views or ephemeral, marts/reporting layers often use tables, and large fact tables typically use incremental.

Coverage checked against the published exam guide on Aug 4, 2026.

These are independent practice questions, written against this certification's published exam guide. They are not the certification vendor's own questions, and not the real exam.