diff --git a/website/docs/community/resources/oss-expectations.md b/website/docs/community/resources/oss-expectations.md
index 762e87d97fb..a57df7fe67f 100644
--- a/website/docs/community/resources/oss-expectations.md
+++ b/website/docs/community/resources/oss-expectations.md
@@ -94,7 +94,7 @@ PRs are your surest way to make the change you want to see in dbt / packages / d
**Every PR should be associated with an issue.** Why? Before you spend a lot of time working on a contribution, we want to make sure that your proposal will be accepted. You should open an issue first, describing your desired outcome and outlining your planned change. If you've found an older issue that's already open, comment on it with an outline for your planned implementation. Exception to this rule: If you're just opening a PR for a cosmetic fix, such as a typo in documentation, an issue isn't needed.
-**PRs should include robust testing.** With the goal to substantially cut down the number and impact of regressions, we are taking a more meticulous approach to the tests that we require to merge a pull request. We recognize that robust testing can often take significantly more effort than the main portion of the code. Thank you for your help in contributing to this goal!
+**PRs should include robust testing.** Comprehensive testing within pull requests is crucial for the stability of our project. By prioritizing robust testing, we ensure the reliability of our codebase, minimize unforeseen issues and safeguard against potential regressions. We understand that creating thorough tests often requires significant effort, and your dedication to this process greatly contributes to the project's overall reliability. Thank you for your commitment to maintaining the integrity of our codebase!"
**Our goal is to review most new PRs within 7 days.** The first review will include some high-level comments about the implementation, including (at a high level) whether it’s something we think suitable to merge. Depending on the scope of the PR, the first review may include line-level code suggestions, or we may delay specific code review until the PR is more finalized / until we have more time.
diff --git a/website/docs/reference/resource-configs/bigquery-configs.md b/website/docs/reference/resource-configs/bigquery-configs.md
index ffbaa37c059..d3497a02caf 100644
--- a/website/docs/reference/resource-configs/bigquery-configs.md
+++ b/website/docs/reference/resource-configs/bigquery-configs.md
@@ -718,3 +718,188 @@ Views with this configuration will be able to select from objects in `project_1.
The `grant_access_to` config is not thread-safe when multiple views need to be authorized for the same dataset. The initial `dbt run` operation after a new `grant_access_to` config is added should therefore be executed in a single thread. Subsequent runs using the same configuration will not attempt to re-apply existing access grants, and can make use of multiple threads.
+
+
+## Materialized views
+
+The BigQuery adapter supports [materialized views](https://cloud.google.com/bigquery/docs/materialized-views-intro)
+with the following configuration parameters:
+
+| Parameter | Type | Required | Default | Change Monitoring Support |
+|-------------------------------------------------------------|------------------------|----------|---------|---------------------------|
+| `on_configuration_change` | `` | no | `apply` | n/a |
+| [`cluster_by`](#clustering-clause) | `[]` | no | `none` | drop/create |
+| [`partition_by`](#partition-clause) | `{}` | no | `none` | drop/create |
+| [`enable_refresh`](#auto-refresh) | `` | no | `true` | alter |
+| [`refresh_interval_minutes`](#auto-refresh) | `` | no | `30` | alter |
+| [`max_staleness`](#auto-refresh) (in Preview) | `` | no | `none` | alter |
+| [`description`](/reference/resource-properties/description) | `` | no | `none` | alter |
+| [`labels`](#specifying-labels) | `{: }` | no | `none` | alter |
+| [`hours_to_expiration`](#controlling-table-expiration) | `` | no | `none` | alter |
+| [`kms_key_name`](#using-kms-encryption) | `` | no | `none` | alter |
+
+
+
+
+
+
+
+
+```yaml
+models:
+ [](/reference/resource-configs/resource-path):
+ [+](/reference/resource-configs/plus-prefix)[materialized](/reference/resource-configs/materialized): materialized_view
+ [+](/reference/resource-configs/plus-prefix)on_configuration_change: apply | continue | fail
+ [+](/reference/resource-configs/plus-prefix)[cluster_by](#clustering-clause): | []
+ [+](/reference/resource-configs/plus-prefix)[partition_by](#partition-clause):
+ - field:
+ - data_type: timestamp | date | datetime | int64
+ # only if `data_type` is not 'int64'
+ - granularity: hour | day | month | year
+ # only if `data_type` is 'int64'
+ - range:
+ - start:
+ - end:
+ - interval:
+ [+](/reference/resource-configs/plus-prefix)[enable_refresh](#auto-refresh): true | false
+ [+](/reference/resource-configs/plus-prefix)[refresh_interval_minutes](#auto-refresh):
+ [+](/reference/resource-configs/plus-prefix)[max_staleness](#auto-refresh):
+ [+](/reference/resource-configs/plus-prefix)[description](/reference/resource-properties/description):
+ [+](/reference/resource-configs/plus-prefix)[labels](#specifying-labels): {: }
+ [+](/reference/resource-configs/plus-prefix)[hours_to_expiration](#acontrolling-table-expiration):
+ [+](/reference/resource-configs/plus-prefix)[kms_key_name](##using-kms-encryption):
+```
+
+
+
+
+
+
+
+
+
+
+```yaml
+version: 2
+
+models:
+ - name: []
+ config:
+ [materialized](/reference/resource-configs/materialized): materialized_view
+ on_configuration_change: apply | continue | fail
+ [cluster_by](#clustering-clause): | []
+ [partition_by](#partition-clause):
+ - field:
+ - data_type: timestamp | date | datetime | int64
+ # only if `data_type` is not 'int64'
+ - granularity: hour | day | month | year
+ # only if `data_type` is 'int64'
+ - range:
+ - start:
+ - end:
+ - interval:
+ [enable_refresh](#auto-refresh): true | false
+ [refresh_interval_minutes](#auto-refresh):
+ [max_staleness](#auto-refresh):
+ [description](/reference/resource-properties/description):
+ [labels](#specifying-labels): {: }
+ [hours_to_expiration](#acontrolling-table-expiration):
+ [kms_key_name](##using-kms-encryption):
+```
+
+
+
+
+
+
+
+
+
+
+```jinja
+{{ config(
+ [materialized](/reference/resource-configs/materialized)='materialized_view',
+ on_configuration_change="apply" | "continue" | "fail",
+ [cluster_by](#clustering-clause)="" | [""],
+ [partition_by](#partition-clause)={
+ "field": "",
+ "data_type": "timestamp" | "date" | "datetime" | "int64",
+
+ # only if `data_type` is not 'int64'
+ "granularity": "hour" | "day" | "month" | "year,
+
+ # only if `data_type` is 'int64'
+ "range": {
+ "start": ,
+ "end": ,
+ "interval": ,
+ }
+ },
+
+ # auto-refresh options
+ [enable_refresh](#auto-refresh)= true | false,
+ [refresh_interval_minutes](#auto-refresh)=,
+ [max_staleness](#auto-refresh)="",
+
+ # additional options
+ [description](/reference/resource-properties/description)="",
+ [labels](#specifying-labels)={
+ "": "",
+ },
+ [hours_to_expiration](#acontrolling-table-expiration)=,
+ [kms_key_name](##using-kms-encryption)="",
+) }}
+```
+
+
+
+
+
+
+
+Many of these parameters correspond to their table counterparts and have been linked above.
+The set of parameters unique to materialized views covers [auto-refresh functionality](#auto-refresh).
+
+Find more information about these parameters in the BigQuery docs:
+- [CREATE MATERIALIZED VIEW statement](https://cloud.google.com/bigquery/docs/reference/standard-sql/data-definition-language#create_materialized_view_statement)
+- [materialized_view_option_list](https://cloud.google.com/bigquery/docs/reference/standard-sql/data-definition-language#materialized_view_option_list)
+
+### Auto-refresh
+
+| Parameter | Type | Required | Default | Change Monitoring Support |
+|------------------------------|--------------|----------|---------|---------------------------|
+| `enable_refresh` | `` | no | `true` | alter |
+| `refresh_interval_minutes` | `` | no | `30` | alter |
+| `max_staleness` (in Preview) | `` | no | `none` | alter |
+
+BigQuery supports [automatic refresh](https://cloud.google.com/bigquery/docs/materialized-views-manage#automatic_refresh) configuration for materialized views.
+By default, a materialized view will automatically refresh within 5 minutes of changes in the base table, but not more frequently than once every 30 minutes.
+BigQuery only officially supports the configuration of the frequency (the "once every 30 minutes" frequency);
+however, there is a feature in preview that allows for the configuration of the staleness (the "5 minutes" refresh).
+dbt will monitor these parameters for changes and apply them using an `ALTER` statement.
+
+Find more information about these parameters in the BigQuery docs:
+- [materialized_view_option_list](https://cloud.google.com/bigquery/docs/reference/standard-sql/data-definition-language#materialized_view_option_list)
+- [max_staleness](https://cloud.google.com/bigquery/docs/materialized-views-create#max_staleness)
+
+### Limitations
+
+As with most data platforms, there are limitations associated with materialized views. Some worth noting include:
+
+- Materialized view SQL has a [limited feature set](https://cloud.google.com/bigquery/docs/materialized-views-create#supported-mvs).
+- Materialized view SQL cannot be updated; the materialized view must go through a `--full-refresh` (DROP/CREATE).
+- The `partition_by` clause on a materialized view must match that of the underlying base table.
+- While materialized views can have descriptions, materialized view *columns* cannot.
+- Recreating/dropping the base table requires recreating/dropping the materialized view.
+
+Find more information about materialized view limitations in Google's BigQuery [docs](https://cloud.google.com/bigquery/docs/materialized-views-intro#limitations).
+
+
diff --git a/website/docs/reference/resource-configs/postgres-configs.md b/website/docs/reference/resource-configs/postgres-configs.md
index 97a695ee12e..8465a5cbb31 100644
--- a/website/docs/reference/resource-configs/postgres-configs.md
+++ b/website/docs/reference/resource-configs/postgres-configs.md
@@ -108,21 +108,100 @@ models:
## Materialized views
-The Postgres adapter supports [materialized views](https://www.postgresql.org/docs/current/rules-materializedviews.html).
-Indexes are the only configuration that is specific to `dbt-postgres`.
-The remaining configuration follows the general [materialized view](/docs/build/materializations#materialized-view) configuration.
-There are also some limitations that we hope to address in the next version.
+The Postgres adapter supports [materialized views](https://www.postgresql.org/docs/current/rules-materializedviews.html)
+with the following configuration parameters:
-### Monitored configuration changes
+| Parameter | Type | Required | Default | Change Monitoring Support |
+|---------------------------|--------------------|----------|---------|---------------------------|
+| `on_configuration_change` | `` | no | `apply` | n/a |
+| [`indexes`](#indexes) | `[{}]` | no | `none` | alter |
-The settings below are monitored for changes applicable to `on_configuration_change`.
+
-#### Indexes
-Index changes (`CREATE`, `DROP`) can be applied without the need to rebuild the materialized view.
-This differs from a table model, where the table needs to be dropped and re-created to update the indexes.
-If the `indexes` portion of the `config` block is updated, the changes will be detected and applied
-directly to the materialized view in place.
+
+
+
+
+```yaml
+models:
+ [](/reference/resource-configs/resource-path):
+ [+](/reference/resource-configs/plus-prefix)[materialized](/reference/resource-configs/materialized): materialized_view
+ [+](/reference/resource-configs/plus-prefix)on_configuration_change: apply | continue | fail
+ [+](/reference/resource-configs/plus-prefix)[indexes](#indexes):
+ - columns: []
+ unique: true | false
+ type: hash | btree
+```
+
+
+
+
+
+
+
+
+
+
+```yaml
+version: 2
+
+models:
+ - name: []
+ config:
+ [materialized](/reference/resource-configs/materialized): materialized_view
+ on_configuration_change: apply | continue | fail
+ [indexes](#indexes):
+ - columns: []
+ unique: true | false
+ type: hash | btree
+```
+
+
+
+
+
+
+
+
+
+
+```jinja
+{{ config(
+ [materialized](/reference/resource-configs/materialized)="materialized_view",
+ on_configuration_change="apply" | "continue" | "fail",
+ [indexes](#indexes)=[
+ {
+ "columns": [""],
+ "unique": true | false,
+ "type": "hash" | "btree",
+ }
+ ]
+) }}
+```
+
+
+
+
+
+
+
+The [`indexes`](#indexes) parameter corresponds to that of a table, as explained above.
+It's worth noting that, unlike tables, dbt monitors this parameter for changes and applies the changes without dropping the materialized view.
+This happens via a `DROP/CREATE` of the indexes, which can be thought of as an `ALTER` of the materialized view.
+
+Find more information about materialized view parameters in the Postgres docs:
+- [CREATE MATERIALIZED VIEW](https://www.postgresql.org/docs/current/sql-creatematerializedview.html)
+
+
### Limitations
@@ -138,3 +217,5 @@ If the user changes the model's config to `materialized="materialized_view"`, th
The solution is to execute `DROP TABLE my_model` on the data warehouse before trying the model again.
+
+
diff --git a/website/docs/reference/resource-configs/redshift-configs.md b/website/docs/reference/resource-configs/redshift-configs.md
index 9bd127a1e1a..b559c0451b0 100644
--- a/website/docs/reference/resource-configs/redshift-configs.md
+++ b/website/docs/reference/resource-configs/redshift-configs.md
@@ -111,40 +111,138 @@ models:
## Materialized views
-The Redshift adapter supports [materialized views](https://docs.aws.amazon.com/redshift/latest/dg/materialized-view-overview.html).
-Redshift-specific configuration includes the typical `dist`, `sort_type`, `sort`, and `backup`.
-For materialized views, there is also the `auto_refresh` setting, which allows Redshift to [automatically refresh](https://docs.aws.amazon.com/redshift/latest/dg/materialized-view-refresh.html) the materialized view for you.
-The remaining configuration follows the general [materialized view](/docs/build/materializations#Materialized-View) configuration.
-There are also some limitations that we hope to address in the next version.
+The Redshift adapter supports [materialized views](https://docs.aws.amazon.com/redshift/latest/dg/materialized-view-overview.html)
+with the following configuration parameters:
+
+| Parameter | Type | Required | Default | Change Monitoring Support |
+|-------------------------------------------|--------------|----------|------------------------------------------------|---------------------------|
+| `on_configuration_change` | `` | no | `apply` | n/a |
+| [`dist`](#using-sortkey-and-distkey) | `` | no | `even` | drop/create |
+| [`sort`](#using-sortkey-and-distkey) | `[]` | no | `none` | drop/create |
+| [`sort_type`](#using-sortkey-and-distkey) | `` | no | `auto` if no `sort`
`compound` if `sort` | drop/create |
+| [`auto_refresh`](#auto-refresh) | `` | no | `false` | alter |
+| [`backup`](#backup) | `` | no | `true` | n/a |
+
+
+
+
+
+
+
+
+```yaml
+models:
+ [](/reference/resource-configs/resource-path):
+ [+](/reference/resource-configs/plus-prefix)[materialized](/reference/resource-configs/materialized): materialized_view
+ [+](/reference/resource-configs/plus-prefix)on_configuration_change: apply | continue | fail
+ [+](/reference/resource-configs/plus-prefix)[dist](#using-sortkey-and-distkey): all | auto | even |
+ [+](/reference/resource-configs/plus-prefix)[sort](#using-sortkey-and-distkey): | []
+ [+](/reference/resource-configs/plus-prefix)[sort_type](#using-sortkey-and-distkey): auto | compound | interleaved
+ [+](/reference/resource-configs/plus-prefix)[auto_refresh](#auto-refresh): true | false
+ [+](/reference/resource-configs/plus-prefix)[backup](#backup): true | false
+```
+
+
+
+
-### Monitored configuration changes
-The settings below are monitored for changes applicable to `on_configuration_change`.
+
-#### Dist
+
-Changes to `dist` will result in a full refresh of the existing materialized view (applied at the time of the next `dbt run` of the model). Redshift requires a materialized view to be
-dropped and recreated to apply a change to the `distkey` or `diststyle`.
+```yaml
+version: 2
-#### Sort type, sort
+models:
+ - name: []
+ config:
+ [materialized](/reference/resource-configs/materialized): materialized_view
+ on_configuration_change: apply | continue | fail
+ [dist](#using-sortkey-and-distkey): all | auto | even |
+ [sort](#using-sortkey-and-distkey): | []
+ [sort_type](#using-sortkey-and-distkey): auto | compound | interleaved
+ [auto_refresh](#auto-refresh): true | false
+ [backup](#backup): true | false
+```
+
+
-Changes to `sort_type` or `sort` will result in a full refresh. Redshift requires a materialized
-view to be dropped and recreated to apply a change to the `sortkey` or `sortstyle`.
+
+
+
+
+
+
+
+```jinja
+{{ config(
+ [materialized](/reference/resource-configs/materialized)="materialized_view",
+ on_configuration_change="apply" | "continue" | "fail",
+ [dist](#using-sortkey-and-distkey)="all" | "auto" | "even" | "",
+ [sort](#using-sortkey-and-distkey)=[""],
+ [sort_type](#using-sortkey-and-distkey)="auto" | "compound" | "interleaved",
+ [auto_refresh](#auto-refresh)=true | false,
+ [backup](#backup)=true | false,
+) }}
+```
+
+
+
+
+
+
+
+Many of these parameters correspond to their table counterparts and have been linked above.
+The parameters unique to materialized views are the [auto-refresh](#auto-refresh) and [backup](#backup) functionality, which are covered below.
+
+Find more information about the [CREATE MATERIALIZED VIEW](https://docs.aws.amazon.com/redshift/latest/dg/materialized-view-create-sql-command.html) parameters in the Redshift docs.
+
+#### Auto-refresh
+
+| Parameter | Type | Required | Default | Change Monitoring Support |
+|----------------|-------------|----------|---------|---------------------------|
+| `auto_refresh` | `` | no | `false` | alter |
+
+Redshift supports [automatic refresh](https://docs.aws.amazon.com/redshift/latest/dg/materialized-view-refresh.html#materialized-view-auto-refresh) configuration for materialized views.
+By default, a materialized view does not automatically refresh.
+dbt monitors this parameter for changes and applies them using an `ALTER` statement.
+
+Learn more information about the [parameters](https://docs.aws.amazon.com/redshift/latest/dg/materialized-view-create-sql-command.html#mv_CREATE_MATERIALIZED_VIEW-parameters) in the Redshift docs.
#### Backup
-Changes to `backup` will result in a full refresh. Redshift requires a materialized
-view to be dropped and recreated to apply a change to the `backup` setting.
+| Parameter | Type | Required | Default | Change Monitoring Support |
+|-----------|-------------|----------|---------|---------------------------|
+| `backup` | `` | no | `true` | n/a |
-#### Auto refresh
+Redshift supports [backup](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-snapshots.html) configuration of clusters at the object level.
+This parameter identifies if the materialized view should be backed up as part of the cluster snapshot.
+By default, a materialized view will be backed up during a cluster snapshot.
+dbt cannot monitor this parameter as it is not queryable within Redshift.
+If the value is changed, the materialized view will need to go through a `--full-refresh` in order to set it.
-The `auto_refresh` setting can be updated via an `ALTER` statement. This setting effectively toggles
-automatic refreshes on or off. The default setting for this config is off (`False`). If this
-is the only configuration change for the materialized view, dbt will choose to apply
-an `ALTER` statement instead of issuing a full refresh,
+Learn more about the [parameters](https://docs.aws.amazon.com/redshift/latest/dg/materialized-view-create-sql-command.html#mv_CREATE_MATERIALIZED_VIEW-parameters) in the Redshift docs.
### Limitations
+As with most data platforms, there are limitations associated with materialized views. Some worth noting include:
+
+- Materialized views cannot reference views, temporary tables, user-defined functions, or late-binding tables.
+- Auto-refresh cannot be used if the materialized view references mutable functions, external schemas, or another materialized view.
+
+Find more information about materialized view limitations in Redshift's [docs](https://docs.aws.amazon.com/redshift/latest/dg/materialized-view-create-sql-command.html#mv_CREATE_MATERIALIZED_VIEW-limitations).
+
+
+
#### Changing materialization from "materialized_view" to "table" or "view"
Swapping a materialized view to a table or view is not supported.
@@ -157,3 +255,5 @@ If the user changes the model's config to `materialized="table"`, they will get
The workaround is to execute `DROP MATERIALIZED VIEW my_mv CASCADE` on the data warehouse before trying the model again.
+
+
diff --git a/website/docs/reference/resource-configs/snowflake-configs.md b/website/docs/reference/resource-configs/snowflake-configs.md
index 30c7966ec68..aa2bf370df6 100644
--- a/website/docs/reference/resource-configs/snowflake-configs.md
+++ b/website/docs/reference/resource-configs/snowflake-configs.md
@@ -346,82 +346,122 @@ In the configuration format for the model SQL file:
## Dynamic tables
-The Snowflake adapter supports [dynamic tables](https://docs.snowflake.com/en/sql-reference/sql/create-dynamic-table).
+The Snowflake adapter supports [dynamic tables](https://docs.snowflake.com/en/user-guide/dynamic-tables-about).
This materialization is specific to Snowflake, which means that any model configuration that
would normally come along for the ride from `dbt-core` (e.g. as with a `view`) may not be available
for dynamic tables. This gap will decrease in future patches and versions.
While this materialization is specific to Snowflake, it very much follows the implementation
of [materialized views](/docs/build/materializations#Materialized-View).
In particular, dynamic tables have access to the `on_configuration_change` setting.
-There are also some limitations that we hope to address in the next version.
+Dynamic tables are supported with the following configuration parameters:
-### Parameters
+| Parameter | Type | Required | Default | Change Monitoring Support |
+|----------------------------------------------------------|------------|----------|---------|---------------------------|
+| `on_configuration_change` | `` | no | `apply` | n/a |
+| [`target_lag`](#target-lag) | `` | yes | | alter |
+| [`snowflake_warehouse`](#configuring-virtual-warehouses) | `` | yes | | alter |
-Dynamic tables in `dbt-snowflake` require the following parameters:
-- `target_lag`
-- `snowflake_warehouse`
-- `on_configuration_change`
+
-To learn more about each parameter and what values it can take, see
-the Snowflake docs page: [`CREATE DYNAMIC TABLE: Parameters`](https://docs.snowflake.com/en/sql-reference/sql/create-dynamic-table).
-### Usage
+
-You can create a dynamic table by editing _one_ of these files:
+
-- the SQL file for your model
-- the `dbt_project.yml` configuration file
+```yaml
+models:
+ [](/reference/resource-configs/resource-path):
+ [+](/reference/resource-configs/plus-prefix)[materialized](/reference/resource-configs/materialized): dynamic_table
+ [+](/reference/resource-configs/plus-prefix)on_configuration_change: apply | continue | fail
+ [+](/reference/resource-configs/plus-prefix)[target_lag](#target-lag): downstream |
+ [+](/reference/resource-configs/plus-prefix)[snowflake_warehouse](#configuring-virtual-warehouses):
+```
-The following examples create a dynamic table:
+
-
+
-```sql
-{{ config(
- materialized = 'dynamic_table',
- snowflake_warehouse = 'snowflake_warehouse',
- target_lag = '10 minutes',
-) }}
-```
-
+
-
+
```yaml
+version: 2
+
models:
- path:
- materialized: dynamic_table
- snowflake_warehouse: snowflake_warehouse
- target_lag: '10 minutes'
+ - name: []
+ config:
+ [materialized](/reference/resource-configs/materialized): dynamic_table
+ on_configuration_change: apply | continue | fail
+ [target_lag](#target-lag): downstream |
+ [snowflake_warehouse](#configuring-virtual-warehouses):
```
-### Monitored configuration changes
+
-The settings below are monitored for changes applicable to `on_configuration_change`.
-#### Target lag
+
-Changes to `target_lag` can be applied by running an `ALTER` statement. Refreshing is essentially
-always on for dynamic tables; this setting changes how frequently the dynamic table is updated.
+
-#### Warehouse
+```jinja
+{{ config(
+ [materialized](/reference/resource-configs/materialized)="dynamic_table",
+ on_configuration_change="apply" | "continue" | "fail",
+ [target_lag](#target-lag)="downstream" | " seconds | minutes | hours | days",
+ [snowflake_warehouse](#configuring-virtual-warehouses)="",
+) }}
+```
+
+
+
+
+
+
+
+Find more information about these parameters in Snowflake's [docs](https://docs.snowflake.com/en/sql-reference/sql/create-dynamic-table):
-Changes to `snowflake_warehouse` can be applied via an `ALTER` statement.
+### Target lag
+
+Snowflake allows two configuration scenarios for scheduling automatic refreshes:
+- **Time-based** — Provide a value of the form ` { seconds | minutes | hours | days }`. For example, if the dynamic table needs to be updated every 30 minutes, use `target_lag='30 minutes'`.
+- **Downstream** — Applicable when the dynamic table is referenced by other dynamic tables. In this scenario, `target_lag='downstream'` allows for refreshes to be controlled at the target, instead of at each layer.
+
+Find more information about `target_lag` in Snowflake's [docs](https://docs.snowflake.com/en/user-guide/dynamic-tables-refresh#understanding-target-lag).
### Limitations
+As with materialized views on most data platforms, there are limitations associated with dynamic tables. Some worth noting include:
+
+- Dynamic table SQL has a [limited feature set](https://docs.snowflake.com/en/user-guide/dynamic-tables-tasks-create#query-constructs-not-currently-supported-in-dynamic-tables).
+- Dynamic table SQL cannot be updated; the dynamic table must go through a `--full-refresh` (DROP/CREATE).
+- Dynamic tables cannot be downstream from: materialized views, external tables, streams.
+- Dynamic tables cannot reference a view that is downstream from another dynamic table.
+
+Find more information about dynamic table limitations in Snowflake's [docs](https://docs.snowflake.com/en/user-guide/dynamic-tables-tasks-create#dynamic-table-limitations-and-supported-functions).
+
+
+
#### Changing materialization to and from "dynamic_table"
-Swapping an already materialized model to be a dynamic table and vice versa.
-The workaround is manually dropping the existing materialization in the data warehouse prior to calling `dbt run`.
-Normally, re-running with the `--full-refresh` flag would resolve this, but not in this case.
-This would only need to be done once as the existing object would then be a dynamic table.
+Version `1.6.x` does not support altering the materialization from a non-dynamic table be a dynamic table and vice versa.
+Re-running with the `--full-refresh` does not resolve this either.
+The workaround is manually dropping the existing model in the warehouse prior to calling `dbt run`.
+This only needs to be done once for the conversion.
For example, assume for the example model below, `my_model`, has already been materialized to the underlying data platform via `dbt run`.
-If the user changes the model's config to `materialized="dynamic_table"`, they will get an error.
+If the model config is updated to `materialized="dynamic_table"`, dbt will return an error.
The workaround is to execute `DROP TABLE my_model` on the data warehouse before trying the model again.
@@ -429,7 +469,7 @@ The workaround is to execute `DROP TABLE my_model` on the data warehouse before
```yaml
{{ config(
- materialized="table" # or any model type eg view, incremental
+ materialized="table" # or any model type (e.g. view, incremental)
) }}
```
@@ -437,3 +477,5 @@ The workaround is to execute `DROP TABLE my_model` on the data warehouse before
+
+