Snowflake、dynamic tablesにadaptive refresh modeとcustom incrementalを追加

Snowflake は 2026年5月26日付の Recent feature updates で、dynamic tables に関する 2 つの Public Preview を追加しました。ひとつは adaptive refresh mode、もうひとつは custom incremental dynamic tables です。どちらも、動的テーブルを単なる便利な自動更新 table としてではなく、より複雑な変換 pipeline の実行基盤として使う流れを強める更新です。

要点

• Adaptive refresh mode for dynamic tables が Public Preview になった
• Custom incremental dynamic tables が Public Preview になった
• 既存の dynamic tables 運用では、refresh mode、incremental eligibility、cost、failure handling の見直しが必要になる
• streams / tasks / stored procedures で実装していた一部 pipeline を dynamic tables に寄せる候補が増える
• Snowflake の Recent feature updates では同じ 5月26日に Iceberg external engine write support GA も並んでおり、data pipeline と open table 運用の両方が動いている

今回のリリースノートで語られていること

Snowflake の 2026年5月26日更新では、Recent feature updates の先頭に dynamic tables 関連の 2 項目が追加されています。Adaptive refresh mode for dynamic tables は Public Preview として掲載され、dynamic tables の refresh behavior をより柔軟に扱う方向の更新です。dynamic tables は、SELECT 定義と target lag をもとに Snowflake が更新を管理する仕組みですが、実際の運用では、query shape、data volume、upstream changes、latency requirement によって full refresh と incremental refresh の選び方が cost と reliability に直結します。

Custom incremental dynamic tables も Public Preview です。従来、dynamic tables は SQL 定義を Snowflake が解釈し、incremental refresh できるかどうかを判断する性格が強い機能でした。custom incremental の方向性は、より複雑な pipeline logic や、streams / tasks で細かく制御していた処理を、dynamic tables の枠組みに取り込む余地を広げるものとして読めます。これにより、data engineering team は「どの変換を dynamic tables に移せるか」を再評価する必要があります。

実務で重要なのは、preview だからといって単純に試すだけでは足りない点です。dynamic tables は upstream tables の変更、refresh history、target lag、warehouse / serverless compute、query compatibility、monitoring と結びつきます。adaptive refresh mode や custom incremental を使う場合、期待した incremental behavior になっているか、full refresh に fallback して cost が跳ねないか、refresh failure をどう検知するか、schema change 時にどう扱うかを確認しなければなりません。

また、同じ Recent feature updates には Snowflake-managed Apache Iceberg tables への external query engine write support GA も並んでいます。これは、Snowflake が managed data pipeline と open table / external engine integration の両方を強化していることを示します。dynamic tables は Snowflake 内部の継続的変換、Iceberg external writes は外部 compute との接続という違いがありますが、どちらも data platform の「どこで変換し、どこで管理し、どこで監査するか」という設計に関わります。

対象になりそうなチーム

• Snowflake dynamic tables を本番 pipeline に使っている data engineering team
• streams / tasks / stored procedures から dynamic tables への移行を検討している platform team
• refresh cost、latency、failure alert、lineage、access history を管理する operations / governance team

実務で確認したいポイント

まず、既存 dynamic tables の refresh mode、target lag、refresh duration、failure history、cost を棚卸ししてください。adaptive refresh mode を試す場合は、before / after で refresh behavior と compute cost を比較できるようにします。custom incremental dynamic tables は、streams / tasks で明示的に差分処理している pipeline のうち、SQL で表現できるものから候補を選ぶのがよさそうです。

Preview 機能なので、本番適用前には rollback 方針も必要です。期待通り incremental にならない場合、full refresh が高コストになる場合、または downstream SLA に影響する場合に、既存 tasks / streams へ戻せる設計にしておくべきです。

結局、この更新をどう見るべきか

今回の Snowflake dynamic tables 更新は、継続的変換 pipeline をより Snowflake-native に寄せるための重要な preview です。便利な自動更新 table としてだけでなく、運用可能な pipeline primitive として評価する段階に入っています。導入判断では、機能可否よりも refresh behavior、cost、監視、rollback を中心に検証するのが現実的です。