Destinations

You must connect a destination to Fivetran so that our connectors can sync data into it from your sources. Fivetran supports cloud data warehouses, databases, online data platforms, and data lakes as destinations.

Supported destinations

Fivetran supports the following destinations:

• Apache Kafka
• Azure Synapse
• BigQuery
• ClickHouse Cloud Partner-Built
• Convex Partner-Built In Dev
• Databricks
• Managed Data Lake Service
• Materialize Partner-Built Private Preview
• MilvusPartner-Built Private Preview
• MotherDuck Partner-Built
• MySQL Beta
• Oracle Beta
• PostgreSQL
• Redshift
• SingleStore Partner-Built Beta
• Snowflake
• SurrealDB Partner-Built Beta
• SQL Server
• Teradata Vantage Partner-Built Private Preview

Let us know if there is a destination that you would like, but that is not yet supported.

Unsupported scenarios

Our load queries are designed to ingest data into your destination as efficiently as possible. However, it is not always possible to load large datasets into row stores like PostgreSQL and MySQL that were designed as operational data stores. If your database is unable to execute our load queries due to data size, you will need to switch to a horizontally scalable column store like Snowflake, Redshift, BigQuery, or Azure Synapse.

Also, we do not support configuring multiple connectors to the same destination table as it can lead to sync failures.

Data types

All destinations contain data in the following types. We may need to convert a few data types to a type accepted by your destination. You can find information about the conversions on the individual destination pages.

For more information about data types, see our Data types documentation.

Type inference

Sources do not always specify data types with great enough specificity for Fivetran to map directly to the destination type. For instance, a source may specify the type as number, when that could mean SHORT, INT, DOUBLE, etc. Or it may provide no types at all, like a bare .csv file. In these situations, Fivetran is capable of inferring the necessary data types, providing an on-the-fly mapping from untyped source values to typed destination values.

Occasionally, there is no good way to even infer a type, like when a type is unknown and no data exists for that column. In this case, Fivetran will not create a destination column, because there is no clear choice as to what type the destination column should have.

For more information about type inference, see our Type inference documentation.

Sync overview

1. Create one or more source connections.
2. Connect target destination.
3. Fivetran does the rest! Extracting, transforming, and loading the data into your destination.

If your destination gets disconnected, we will still keep a record of the progress that we've made for every source connection. Fivetran maintains an internal set of progress cursors which is recorded when an update is successfully synced. This provides an air-tight handoff between syncs so that no data is ever missed. Because of this, Fivetran's system is extremely tolerant to service interruptions. If there is an interruption in your service, such as your destination going down, Fivetran will automatically resume syncing exactly where it left off after your destination is live again (even if it's days or weeks later).

Destination costs

Fivetran uses queries to load data into your destination. If your service provider charges for compute usage, they will charge you when Fivetran loads data into your destination. Two main factors influence your costs:

• Data volume: Loading large amounts of data costs more.
• Sync frequency: Syncing data frequently may cost more, depending on how often updates happen in your source. In your Fivetran dashboard, you can choose how frequently your syncs run, from every 5 minutes to every 24 hours.

The costs vary depending on your service provider. For more information, see the individual destination pages.

Schema and table management

Fivetran uses the Destination schema name you provide in the connection setup form to create the schema in your destination. By default, we use the connection name as the destination schema name. The destination schema name is permanent and cannot be changed.

Fivetran creates, delivers, and manages the base tables to your destination. Base tables are the direct replicated tables from the source, that you use as the building blocks to build your analysis. Fivetran maintains an internal representation of the tables and schemas that we deliver. On every update, we check against this internal representation to identify any schema changes in the source. We do not build our internal representation from your destination.

Let Fivetran do the mapping

Fivetran creates the mapping between source objects/columns and your destination tables/columns. When you add a column or otherwise make a change to the source schema, that change will be detected and pushed into your destination automatically.

Updating Fivetran-delivered tables

If you make manual changes to the destination tables, during any subsequent updates, the schema/tables will be updated as though your changes had not been made. If you manipulate the tables in your destination, our internal representation will not be updated, and the schema migrations and updates will not occur as expected. Fivetran essentially manages the base tables in your destination, so it's best not to manipulate these tables. Instead, you can create views referencing these tables with the desired changes.

There are certain optimizations that you can apply to your destination tables (sort keys, dist. keys, etc.) that Fivetran will not interfere with. These changes are destination-specific, so check the individual destination page for more information on each.

Schema migrations

On each update, we compare the incoming data to the internal record of what we have already delivered to your destination, looking for:

1. New objects/tables
2. New columns
3. Column type changes

[Overview Fivetran Automatic Schema Migration]

Table changes

When we see new objects or tables in your source, we will automatically create them as tables in your destination. Any objects that are deleted from the source are left untouched as tables in your destination, remaining in the state they were in at the last update. Renamed objects will be treated as a new table and a deleted table.

Column changes

Our sync is in one direction: from the data source (a SaaS application, database, etc.) to your destination, but not the other way around.

New columns in a source table are added in your destination, and we trigger a full re-import or incremental sync of the table.

We treat renamed columns as two: a new column and a deleted column.

Deleted columns are handled in one of two ways:

• Some connectors leave the deleted column in your destination with its previous data intact and add NULL values from its delete date forward. If the table is re-synced, the previous data in the deleted column is removed.

• Certain connectors replace all values in the deleted column with NULL values. The connectors are:

  • Db2 for z/OS
  • MySQL (includes Generic MySQL, Amazon Aurora MySQL, Amazon RDS MySQL, Azure Database for MySQL, Google Cloud MySQL)
  • Oracle (includes Generic Oracle, Oracle RAC, Amazon RDS Oracle, High-Volume Agent Oracle)
  • SQL Server (includes only High-Volume Agent SQL Server)
  • Snowflake

Column type changes

When you change the data type of a column in your source, we look at whether it is a widening or a narrowing change.

• If it is a widening change (for example, when you change a column type from INT to LONG), we update the column type in your destination.

• If it is a narrowing change (for example, when you change a column type from LONG to INT), we do not update the column type in your destination.

Primary key changes

When you change the primary key in your source, you may observe duplicate records or other data integrity issues in your destination.

We have detected data integrity issues in the destination when:

• the primary key is initially a combination of two or more columns and is later changed to a single column. For example, id and row_id to product_id.
• the primary key column changes. For example, id to row_id.

If you change the primary key for a database or application connection, we recommend dropping the existing table from the destination and re-syncing the table.

Long value truncation

Destinations have different maximum allowed lengths for JSON, STRING, and BINARY type columns.

If a value in a JSON column exceeds the maximum allowed length for your destination, it is replaced with a JSON error message reading {"FIVETRAN ERROR": "Original value could not be synced because it exceeded your warehouse's maximum length of N"}, where N is the maximum column length your destination allows.

If a value in a STRING column exceeds the maximum allowed length, it is truncated to the maximum length allowed.

If a value in a BINARY column exceeds the maximum allowed length, it is replaced with null. A warning message reading "encoded_binary_string_too_long", "A record containing a Base64 encoded binary value that was over <max binary allowed in your warehouse> characters in length of your warehouse limit, in the '<column name>' column of the '<schema name>'.'<table name>' table, was overwritten with null value." is displayed on the Fivetran dashboard.

If a value in an XML column exceeds the maximum allowed length for your destination, it is replaced with an XML error message reading <errmsg> <error>FIVETRAN_ERROR</error> <message>Original value could not be synced because it exceeded your warehouse's maximum length of N </message> </errmsg>, where N is the maximum column length your destination allows.

Date and time value range

Every destination defines its own supported ranges for date and time data types. Fivetran aligns with those limits during data loading to ensure compatibility. However, most destinations support year values in the range 0001 to 9999. For the exact supported limits, see your destination's documentation.

The 00019999 year range applies to the following Fivetran data types:

If the source sends a date or time value outside this range, Fivetran replaces the value with NULL during sync.

If your source data contains values outside the supported range, contact our support team.

Connecting your destination

Fivetran must be able to connect to your destination to deliver data because our connectors follow a push strategy. We support the following connection methods:

• Direct connection by safelisting Fivetrans IP
• SSH tunnel
• Reverse SSH tunnel
• AWS PrivateLink, Azure Private Link, or Google Cloud Private Service Connect (Business Critical only)
• Private Google Access
• VPN tunnel

For more information about the connection methods, see our Destination Connection Options documentation.

Connecting multiple destinations

Fivetran supports multiple destinations per Fivetran account. Each destination has separate connections, users, and access permissions.

Common use cases for multiple destinations are:

• maintaining a second "testing" destination for BI experimentation
• isolating users from having access to other connections
• trialing another type of destination temporarily

Instructions

To add another destination, go to the Destinations page and click Add destination. You must have an Account Administrator, Destination Creator role or a custom role with the Create Destinations permissions in your Fivetran account to add a destination.

Choosing your data processing location and cloud service provider

Fivetran runs data connectors on servers in the US, EU, Australia, UK, Canada, Singapore, and India regions. Configure the geography you want to use in your destination settings.

Instructions

1. On your Fivetran dashboard, select Destination.
2. Find and select the destination you want to update.
3. On the destination overview page, click Actions and then click Edit connection details.
4. Use the Data processing location drop-down menu to select the region from which you'd like Fivetran to run your syncs.
5. If you are on an Enterprise or Business Critical plan, select the Cloud service provider.
6. If you are on a Business Critical plan, select the AWS region, Azure region, or GCP region respectively.

Choosing your time zone

Fivetran uses your destination time zone to determine when to start your syncs. Our time zones are all Coordinated Universal Time (UTC) offsets - for example, Pacific Standard Time is UTC-08. Configure the time zone you want to use in your destination settings.

By default, we do not shift your UTC offset with daylight saving time. For example, you have syncs set to run every 24 hours at 2 a.m. Once daylight saving time begins, your syncs start at 3 a.m. local time. To preserve your sync start time, you can choose to automatically update your time zone when the US observes daylight saving time (from the second Sunday in March to the first Sunday in November). You can also manually change your time zone to match daylight saving time in your region.

Instructions

1. On your Fivetran dashboard, select Destination.
2. Find and select the destination you want to update.
3. Click Actions and then click Edit connection details.
4. Use the Time zone drop-down menu to select your chosen time zone.
5. (US only) To automatically update your time zone when daylight saving time begins or ends, set the Shift my UTC offset with daylight saving time (US Only) toggle to ON before daylight saving time begins.
   The daylight saving time toggle only works if it is set to ON during the time shift. For example, if you had the toggle on but turned it off before daylight saving time ends, we do not automatically update your time zone to standard time.

Switching destinations

If you want to migrate to a different type of destination, you should first create a second destination by going to the Destinations page and clicking Add destination. By request, contact our support team can copy your connection configurations to a new destination. The new connections will still need to perform an initial sync. Once you have completed the migration, remember to pause the connections for your old destination.

Supported character sets

Fivetran supports UTF-8 character encoding across all destinations. However, some destinations store specific data types using different encodings. For more information about the character encoding used by your destination, see the destination documentation.