5 things to know about where Fivetran sends your data

Most conversations about data integration focus on the source side — which connectors exist, how they handle schema changes, how reliably they sync. The destination side gets less attention, but it's where the consequences of design decisions play out most directly. The destination is where your analysts query, where your dbt models run, where your AI models train, and where your business decisions get made. Getting it right matters.

Fivetran's approach to destinations reflects a broader philosophy: the destination should be a first-class concern, not an afterthought. Consistent schema semantics across every warehouse, choice of sync mode at the table level, native support for open lake formats with automatic catalog registration, and a reverse ETL layer that keeps the warehouse from becoming a data dead end. Here are the 5 things that define how Fivetran thinks about destinations.

[CTA_MODULE]

1. Consistent schemas everywhere

One of the most valuable but least-advertised properties of Fivetran's destination layer is schema consistency. When Fivetran loads data into a destination, it uses a standardized type system — mapping source data types to a canonical set of Fivetran types (string, integer, float, boolean, date, timestamp, JSON, binary) and then mapping those to the nearest equivalent in the target destination. This means a pipeline loading data into Snowflake and one loading the same data into Databricks will produce tables with the same names, the same column names, and semantically equivalent types.

In practice, this means that dbt models, Quickstart packages, and SQL transformation logic are portable across destinations. A Quickstart package for Salesforce that produces a clean revenue analytics layer in Snowflake will produce the same layer in BigQuery or Databricks without modification. A dbt project developed against a Redshift destination can be pointed at Snowflake with minimal changes. This portability eliminates one of the most common sources of migration friction — the need to revalidate or rebuild analytical assets when the underlying warehouse changes. Fivetran also adds 2 metadata columns to every destination table — _fivetran_synced (the timestamp of the last successful sync for that row) and _fivetran_deleted (a boolean marking rows soft-deleted in the source) — which are consistent across all destinations.

2. Two sync modes: Soft delete and history mode (SCD Type 2)

Every table Fivetran syncs to a destination operates in 1 of 2 modes, configurable per table without any code. Soft delete mode — the default — maintains a current-state view of each table. When a record is deleted in the source, Fivetran doesn't remove it from the destination. Instead, it marks the row with _fivetran_deleted = TRUE, preserving the data while making it easy to exclude deleted records from queries with a simple WHERE clause. When a record is updated, the destination row is updated in place. The result is a destination table that accurately reflects the current state of the source, with full recovery of deleted records if needed.

History mode implements Type 2 Slowly Changing Dimensions (SCD2) natively — no custom dbt models, no separate historical table, no manual timestamp management. When history mode is enabled for a table, every change in the source inserts a new row rather than updating the existing one. Three system columns manage the history: _fivetran_start (when this version of the record became active), _fivetran_end (when it was superseded, or the maximum possible timestamp if still current), and _fivetran_active (a boolean convenience flag for filtering to the current version). This makes point-in-time analysis and trend reporting against source data possible with nothing more than enabling a toggle in the schema configuration. History mode can be switched on and off per table, and Fivetran runs migration queries automatically when you change modes — existing data is restructured to the new format without any data loss.

3. Open lake formats and multi-engine queries

Fivetran's Managed Data Lake Service takes the destination concept beyond the warehouse. Instead of loading into a proprietary warehouse format, it writes directly to cloud object storage — Amazon S3, Azure Data Lake Storage, or Google Cloud Storage — in open table formats: Apache Iceberg^TM or Delta Lake. The result is data that no single vendor controls. The same Iceberg tables Fivetran creates can be queried simultaneously by Snowflake using external Iceberg tables, Databricks via Unity Catalog, Amazon Athena via AWS Glue, BigQuery via BigLake Metastore, and Apache Spark via the Fivetran Catalog — all reading the same physical files with no data duplication and no replication pipelines between engines.

The catalog registration step — historically the friction point in multi-engine lake architectures — is automated by Fivetran. The Managed Data Lake Service ships with a pre-configured Fivetran Catalog (built on Apache Polaris^TM) as the default. It also supports automatic registration with AWS Glue (giving access to the full AWS ecosystem including EMR and Athena), Databricks Unity Catalog (governance, lineage, and fine-grained access control across Delta tables), and Google BigLake Metastore. Every time a sync completes, Fivetran updates the relevant catalog so downstream query engines immediately see the latest data — without any manual DDL, REFRESH commands, or scheduled crawlers.

4. Destinations are the start of activations

The warehouse is where data becomes trustworthy — governed, modelled, enriched, and consistently structured. But trustworthy data sitting in a warehouse dashboard isn't the end state most businesses need. Sales reps work in Salesforce, not in Snowflake. Marketing teams build campaigns in HubSpot, not in BigQuery. Customer success teams monitor churn signals in their CRM or CS platform, not in SQL queries. The analytical intelligence built in the warehouse needs a way back into the operational systems where business teams actually work.

Fivetran Activations is the reverse ETL layer that closes this loop. It reads data from your warehouse — customer segments, health scores, churn propensity models, product usage summaries, enriched contact records — and syncs it back to operational tools on a defined schedule. Supported activation destinations include Salesforce and Salesforce Marketing Cloud, HubSpot, Braze, ActiveCampaign, Iterable, Zendesk, Google Ads, Meta Ads, Slack, Microsoft Fabric, Webflow, and more — covering CRM, marketing automation, customer success, advertising, and communication platforms. The same data model that powers the BI dashboard also powers the sales rep's CRM, the marketer's email segment, and the customer success manager's health score view — from a single governed source.

5. Support for multiple destinations

The modern data estate is rarely homogeneous. An enterprise data team might run Snowflake for SQL analytics, Databricks for machine learning, S3 with Iceberg for cost-effective historical archival, PostgreSQL as the backend for an internal data product, and ClickHuse for a high-concurrency customer-facing analytics feature. These aren't competing choices — they're appropriate tools for different workloads. Fivetran's destination library supports all of them from a single platform, without requiring a different ingestion tool for each architectural layer.

Fivetran currently supports over 30 destination types across every major category of data infrastructure. The full destination landscape spans cloud data warehouses, open data lakes in multiple formats, specialized analytical databases, relational databases, streaming platforms, and vector databases for AI workloads. All destinations share the same connector coverage — the same 750+ source connectors work with every destination. All destinations benefit from the same schema consistency, metadata columns, sync mode options (soft delete and history), and governance capabilities. Hybrid Deployment is available for destinations with strict data residency requirements, keeping data processing within your own network boundary.

The destination is a first-class decision

Consistent schemas that make analytical assets portable. Two sync modes that handle current-state and full historical tracking at the table level without any custom code. Open lake formats that let multiple engines query the same data concurrently with automatic catalog registration. Activations that ensure the intelligence built in the warehouse reaches the operational tools that act on it. And a destination library that covers every architecture from traditional warehouses to open lakes, analytical databases, streaming platforms, and vector stores.

Wherever your data needs to land — and wherever it needs to go next — Fivetran has the destination covered.

Apache Iceberg and Apache Polaris are trademarks of the Apache Software Foundation.

[CTA_MODULE]