Fivetran、legacy table と _UPCOMING table の並行同期期間を案内

Fivetran の changelog に、2026年7月14日まで従来テーブルと _UPCOMING suffix 付きの新テーブルへ並行してデータを同期する、という 2026年6月10日の更新が掲載されました。新しいテーブルでは _fivetran_id が主キーとして使われると説明されています。

要点

• 2026年7月14日まで、従来テーブルと対応する _UPCOMING suffix 付き新テーブルに並行同期される
• 新テーブルでは _fivetran_id が主キーとして使われる
• 既存の下流クエリ、BI ダッシュボード、dbt モデル、品質チェックが従来テーブル名や主キー前提に依存していないか確認したい
• 対象コネクターを使っているチームは、並行期間中に新テーブル側で検証を終える必要がある

今回の変更で何が変わるのか

今回の更新は、新しいコネクター スキーマへの移行期間を明示するものです。Fivetran は一定期間、既存の従来テーブルと、新しい _UPCOMING suffix 付きテーブルの両方に同期します。つまり、利用者は本番の下流処理をいきなり切り替えるのではなく、同じデータ連携から出る新旧のテーブルを比較しながら、クエリ、変換、レポート、監視ルールを移行できます。

実務上のポイントは、テーブル名だけでなく主キーの前提も変わることです。新テーブルで _fivetran_id が主キーとして使われる場合、既存の重複排除、差分更新モデル、結合、データ品質テストが旧スキーマのキー前提に寄っていると、移行後に重複検知や差分抽出の結果が変わる可能性があります。特に、Fivetran の raw テーブルを直接参照している BI やノートブック、dbt モデルがある環境では、影響範囲を機械的に洗い出したい更新です。

また、並行同期期間が 2026年7月14日までと区切られている点も重要です。期限を過ぎる前に _UPCOMING 側の行数、主キーの一意性、NULL 許容列、既存ダッシュボードの集計結果を確認し、切り替え手順とロールバックの扱いを決めておく必要があります。更新そのものは小さな changelog item に見えますが、データ基盤では下流依存が広がりやすい種類の変更です。

対象になりそうなユーザー・チーム

• Fivetran コネクターの raw テーブルを dbt、SQL ジョブ、BI ダッシュボードから参照しているデータ基盤チーム
• 主キーや一意キーを前提に差分更新モデル、重複排除、品質テストを組んでいる analytics engineering チーム
• 2026年7月14日までにスキーマ マイグレーションの検証計画を作る必要がある platform / operations チーム

実務でまず確認したいこと

1. 対象コネクターの従来テーブルと _UPCOMING テーブルを特定する
2. 下流クエリ、dbt モデル、ダッシュボード、アラート、ノートブックが従来テーブル名を直接参照していないか検索する
3. _fivetran_id を主キーとしたときの一意性、行数、結合結果を旧テーブルと比較する
4. 2026年7月14日までに切り替える owner、検証手順、ロールバック方針を決める

どう読むべきか

この更新は、単なるスキーマ告知ではなく、移行期限付きの互換期間として読むのが安全です。Fivetran 側が新旧テーブルを並行同期している間に、downstream の参照と key 前提を洗い出し、新テーブルへ移す準備を進めたいところです。