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.

1 · Learn the must-know

• 1Views 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.
• 2Table 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.
• 3Incremental 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.
• 4Ephemeral 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.
• 5Incremental 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.
• 6Materialization 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.

2 · Check your understanding