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.

NOTE: Destinations were previously called "warehouses" in our documentation because we originally only supported data warehouses as destinations.

Supported destinations

Fivetran supports the following destinations:

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.

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.

Data Type
BOOLEAN
SHORT
INT
LONG
BIGDECIMAL
FLOAT
DOUBLE
LOCALDATE
LOCALDATETIME
INSTANT
STRING
XML
JSON
BINARY

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

Create one or more source connectors.
Connect target destination.
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 connector. 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 connector setup form to create the schema in your destination. By default, we use the connector 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.

IMPORTANT: Any schema changes that you make to the destination tables will not be captured in our internal representation.

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:

New objects/tables
New columns
Column type changes

Overview Fivetran Automatic Schema Migration

NOTE: Fivetran doesn't scan your destination during every update, but rather has an internal understanding of the tables/schemas that we have already delivered. If you manipulate the tables in your destination, our internal representation will not be updated, and the schema migrations will not occur as explained. Fivetran essentially manages the base tables in your destination so, as a rule, it's best not to manipulate these tables, but rather to create views referencing these tables with the desired changes.

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. Re-named 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 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, then add NULL values from its delete date forward. If the table is re-synced, the previous data in the deleted column is removed.

Other connectors replace all values in the deleted column with NULL values. These connectors are as follows:

Generic MySQL
Amazon Aurora MySQL
Amazon RDS MySQL
Azure Database for MySQL
Google Cloud MySQL
Generic Oracle
Oracle RAC
Amazon RDS Oracle
High-Volume Agent Oracle
High-Volume Agent SQL Server
Snowflake Beta

IMPORTANT: If you manually added a column to your destination's schema table that causes inconsistencies, we do not manage those inconsistencies. If this occurs, the next sync cycle won't be successful. The solution for this is to delete the columns that you manually added to your destination's schema table and wait for the next sync to begin, at which point new attributes from your data source will be created/synced into your destination.

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 database connectors and application connectors (such as Salesforce or NetSuite SuiteAnalytics), we recommend dropping the existing table from the destination and re-syncing the table.

NOTE: Monthly Active Rows (MAR) (MAR) is the number of distinct primary keys synced from the source system to your destination in a given calendar month. We separately count primary keys by account, destination, connector, and table. Changing the primary key in your source will impact your MAR.

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.

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 Fivetran’s 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 connectors, 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 connectors
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.

NOTE: Depending on the plan you are on, you can also select the cloud service provider and cloud region. See our Data Residency documentation for details.

Instructions

On your Fivetran dashboard, select Destination.
Go to the Edit connection details tab.
Use the Data processing location drop-down menu to select the region from which you'd like Fivetran to run your syncs.
If you are on an Enterprise or Business Critical plan, select the Cloud service provider.
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.

NOTE: We call the UTC offsets by their standard names. For example, UTC-05 is called Eastern Standard Time, not Central Daylight Time.

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

On your Fivetran dashboard, select Destination.
Go to the Edit connection details tab.
Use the Time zone drop-down menu to select your chosen time zone.
(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.
IMPORTANT: 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, Fivetran Support can copy your connector configurations to a new destination. The new connectors will still need to perform an initial sync. Once you have completed the migration, remember to pause the connectors for your old destination.

Supported character sets

We only support UTF-8 character set for our destinations.