Release Notes
May 2025
We now convert the LOCALDATETIME data type to DATETIME(6) in your destination, instead of DATETIME. This change increases timestamp precision from seconds to microseconds, helping us store more accurate date and time values.
This change applies to all new connections created on or after May 7, 2025. To upgrade the mapping for an existing connection, contact our support team.
September 2024
All MySQL implementations now support the Hybrid Deployment model. We are gradually rolling out this feature to all existing destinations. For more information, see the individual destination setup guides.
June 2023
We now support AWS PrivateLink for the following destinations:
- Amazon Aurora PostgreSQL
- Amazon RDS PostgreSQL
- Aurora MySQL
- MariaDB MySQL
- Amazon RDS for MariaDB MySQL
- MySQL
- Amazon RDS for MySQL
- PostgreSQL
- SQL Server
- Amazon RDS for SQL Server
January 2021
We have fixed a bug where TIME values were sometimes synced to the destination incorrectly. Previously, we added a .0 to values with no decimals and dropped the hundredths place for values that did. We now sync TIME values to the destination as they appear in the source:
| Source value | Destination value (with bug) | Destination value (fixed) |
|---|---|---|
23:59:59 | 23:59:59.0 | 23:59:59 |
23:59:59.00 | 23:59:59.0 | 23:59:59.00 |
23:59:59.10 | 23:59:59.1 | 23:59:59.10 |
If any values were incorrectly synced prior to this change, you will need to initiate a historical re-sync or table re-sync to correct them.
June 2020
We now replicate empty tables in a PostgreSQL source database as empty tables in the destination.
November 2019
We now officially support Aurora RDS MySQL as one of our destinations.
See our Aurora RDS MySQL setup instructions.
August 2019
We have changed the MySQL version requirements for Fivetran to store data as JSON in a MySQL destination and create tables with primary keys.
We now convert JSON to TEXT in versions below 5.7.8.
We now create primary keys in either of the following scenarios:
MySQL version earlier than 5.7.7:
- If the total number of primary keys provided by the source is less than 16, and the sum of the byte length of STRING primary keys is less than 191.
MySQL version 5.7.7 and later:
- If the total number of primary keys provided by the source is less than 16, and the sum of the byte length of STRING primary keys is less than 768.
January 2019
Fivetran will create primary keys for a MySQL destination in either of the following scenarios:
MySQL version earlier than 5.7 or MariaDB version earlier than 10.2: If the source provides fewer than 16 primary keys and the sum of the byte length of STRING primary keys is less than 191.
MySQL version 5.7 and later or MariaDB version 10.2 and later: If the source provides fewer than 16 primary keys and the sum of the byte length of STRING primary keys is less than 768.
October 2018
For the following destinations, Fivetran now drops the primary_key field from existing tables in your destination if there is a primary_key coming in from your data source:
- MySQL
- PostgreSQL
- SQL Server
- Redshift
September 2018
The MySQL destination now uses the load data infile strategy to write data. It requires the load_infile system variable to be set to on. For additional details, refer to our MySQL destination documentation.
August 2018
STRING values will now be created as LONGTEXT columns in the MySQL destination instead of VARCHAR fields if they are not the primary key. We made this change to better handle MySQL's maximum row size limit.
April 2018
If your destination uses a MySQL version earlier than 5.7, you can't use the timestamp column as a primary key because MySQL incorrectly handles the decimal part of the timestamp. We now detect this scenario, skip tables with this column during our sync, and warn you to upgrade your destination MySQL version. Note that this limitation only applies to MySQL destinations, not MySQL sources.