Release Noteslink
February 2024link
We now support PostgreSQL version 16. Read our PostgreSQL documentation for more information.
We now sync unknown data types to the destination as strings.
November 2023link
We have made the following changes to the Fivetran Teleport Sync update method:
- We no longer read for changes from columns that were selected and later deselected or update their
fivetran_synced
dates - We no longer require a historical re-sync to bring in new data when you select new columns from the schema
August 2023link
We can now sync tables with TEXT primary keys using Fivetran Teleport Sync. For more information, see our PostgreSQL documentation.
July 2023link
We have added support for XML data type transformation. For more information about the supported data types, see our PostgreSQL documentation.
June 2023link
We now support syncing the LTREE data type. See all supported data types in our PostgreSQL documentation.
May 2023link
We can now sync tables with DATE primary keys using Fivetran Teleport Sync. For more information, see our PostgreSQL documentation.
March 2023link
We now support PostgreSQL version 15. Read our PostgreSQL documentation for more information.
We are deprecating the logical replication with the test_decoding
plugin update method. We are gradually migrating all users who use this method to logical replication with the pgoutput
plugin. If you use the test_decoding
method, we generate a warning message in your Fivetran dashboard that contains instructions for migrating to the pgoutput
method. Follow the steps in that message to complete your migration. To learn about the differences between the pgoutput
method and the test_decoding
method, see our logical replication documentation.
We now support the TRUNCATE
command for the pgoutput
update method. If a table is truncated, the records prior to the TRUNCATE
timestamp appear as _fivetran_deleted=true
in the destination. If you are using history mode, the truncated table is deleted in your destination, just like a regular delete.
We now sync bounds information for DATERANGE, TSRANGE, and TSTZRANGE data types to the destination, where the values EXCLUSIVE
and INCLUSIVE
indicate the bounds.
February 2023link
We added an additional layer of validation to proactively catch mismatches between PostgreSQL sources and Snowflake destinations, such as missing rows. We are gradually rolling out this new feature to all PostgreSQL connectors sending data to Snowflake.
January 2023link
We now support Amazon Aurora Serverless PostgreSQL. Read our PostgreSQL documentation for more information.
We can now sync tables with constrained NUMERIC primary keys using Fivetran Teleport Sync. Learn more in our Fivetran Teleport Sync for PostgreSQL documentation.
December 2022link
We no longer support PostgreSQL version 8. We only support PostgreSQL versions 9 - 14.x.
November 2022link
We now sync incremental data from partitioned tables into the parent table. This change applies to new connectors created on or after November 8, 2022. For connectors created before November 8, 2022, we sync incremental data from partitioned tables into partitions. If you want to sync incremental data into the parent table, contact Fivetran Support.
October 2022link
Fivetran Teleport Sync is now generally available. Learn more in our Fivetran Teleport Sync for PostgreSQL documentation.
June 2022link
Fivetran Teleport Sync is now available in beta. Learn more in our Fivetran Teleport Sync for PostgreSQL documentation.
April 2022link
The PostgreSQL connectors now only use soft deletes in the Soft Delete sync mode with all incremental update mechanisms. History mode doesn't use soft deletes regardless of your incremental update mechanism.
We fixed a bug that made our PostgreSQL connectors fail to parse arrays of complex types like POINT, TSRANGE, and TSTZRANGE for tables without primary keys. For these types, we now sync the raw values to the destination.
October 2021link
We now support logical replication using the pgoutput
plugin. The pgoutput
plugin allows you to use PostgreSQL's publications feature. This feature only replicates change events from tables in your publication, so you control which changes are replicated to Fivetran. Learn more in our pgoutput
plugin documentation.
July 2021link
We now support logical replication in Google Cloud PostgreSQL. Learn more in about logical replication in our Updating data documentation.
January 2021link
We now support domains, which are user-defined data types with optional constraints. Learn more in PostgreSQL's domains documentation.
We now support logical replication on Azure PostgreSQL version 9.5 and later.
December 2020link
We now enforce stricter checks on the replication slot's configuration during the setup tests. Ensure that a replication slot exists within the database you specify and turn on the "test_decoding" plugin.
We now support logical replication on Azure PostgreSQL versions 10 and newer.
We have now made the GEOMETRY and GEOGRAPHY data types GeoJSON compliant.
October 2020link
We now sync unparsable DATERANGE values (such as 10000-01-01
) to the destination as null values.
August 2020link
We have added support for PostgreSQL's email domain. We treat this domain as an extension of CITEXT data type. Learn how we map CITEXT data types to your destination in our PostgreSQL documentation.
July 2020link
We now support logical replication on Aurora PostgreSQL versions 10.6 or later.
June 2020link
We now replicate empty tables in a PostgreSQL source database as empty tables in the destination.
May 2020link
We now support syncing the BYTEA data type from your source. In your destination, the BYTEA data type will appear as BINARY data type.
February 2020link
We now support partitioned tables. You will be able to see both partitioned tables and their partitions in your Fivetran dashboard.
December 2019link
We now create a task on your Alerts page when we encounter concurrent usage errors for your replication slot. Only one process can access the same replication slot at a time. For more details, see PostgreSQL's logical decoding documentation.
We can now use unique indexes to import tables without a primary key, making imports more efficient and reliable. This fix will be gradually rolled out over the next few weeks.
November 2019link
We can now use unique key constraints to import tables without a primary key, making imports more efficient and reliable. This fix will be gradually rolled out over the next few weeks.
We now require that the PostgreSQL database configuration parameter
statement_timeout
is either0
(the default value to disable the timeout) or is greater than5 minute
. Fivetran validates this value during the setup test.
October 2019link
- We can now sync single- and multidimensional JSON, JSONB, and HSTORE arrays.
- We now require that the postgres database configuration parameter 'wal_sender_timeout' is set to 0 or greater than 10 minutes. The value is validated during the setup test.
September 2019link
If you have a logging service connected to your Fivetran account, the import progress of your tables in the event logs will be visible in your logs as an import_progress
event. Table names will be in either the COMPLETE
or IN_PROGRESS
state, depending on their sync status. Tables that are not reported in the event have not started their import.
August 2019link
We fixed a bug that caused connectors to break when syncing Postgis Geometry/Geography objects.
July 2019link
We have fixed a bug in our PostgreSQL connectors which was preventing some syncs from making progress.
Previously, PostgreSQL connectors using WAL syncs could not make progress through the WAL if all of the log events were related to tables Fivetran did not sync. For example, if you selected to sync the table PUBLIC.MY_TABLE
, and all log events were on PUBLIC.YOUR_TABLE
, Fivetran could not make progress.
Now Fivetran clears the WAL slot to the most recent LSN we examined if no rows were added, deleted, or updated in Fivetran-delivered tables.
March 2019link
Fivetran has added core support for a TIMESTAMP WITHOUT TIMEZONE type. Up until now, Fivetran assumed that timestamps without timezone were in UTC. This addition means databases with a TIMESTAMP WITHOUT TIMEZONE type - MySQL, Oracle, PostgreSQL, SQL Server - will replicate to a more correct destination type. TIMESTAMP WITHOUT TIMEZONE support is immediately available for Oracle, PostgreSQL, and SQL Server. MySQL / MariaDB support will be released soon.
Source | Applicable Type |
---|---|
Oracle | TIMESTAMP |
PostgreSQL | TIMESTAMP |
SQL Server | DATETIME, DATETIME2, SMALLDATETIME |
MySQL / MariaDB | DATETIME |
This change is backwards compatible. Fivetran's core will continue assuming UTC time zone if the destination type is TIMESTAMP WITH TIMEZONE. In order to get the more specific type, drop the table in the destination and re-sync the table in your Fivetran dashboard.
We are changing our architecture to allow for much higher data throughput. Starting on April 30, 2019, all Fivetran connectors will originate from a new set of fixed IP addresses. For the US region, these IPs are:
- 35.227.135.0/29
- 35.234.176.144/29
- 52.0.2.4/32.
Update your IP safelists for the following databases and warehouses before April 30. Not doing so will result in a connection failure.
Databases:
- MariaDB
- MongoDB
- MySQL
- Oracle
- PostgreSQL
- SQL Server
Warehouses:
- Redshift
- Azure Synapse
- Snowflake
If you don't use any of the above databases or warehouses with Fivetran, you don't need to take any action.
February 2019link
TIMESTAMP
column types will now be represented asTIMESTAMP WITHOUT TIME ZONE
in the destination.TSRANGE
columns will be represented as JSON, with timestamps without timezones encoded as strings.
November 2018link
You can now trigger re-syncs of individual tables from your Fivetran dashboard:
The re-sync button appears when you hover your cursor over the row that contains the table name.
This feature is available for the following connectors:
- DynamoDB
- MongoDB
- MySQL
- NetSuite SuiteAnalytics
- Oracle
- PostgreSQL
- Salesforce
- SQL Server
- Zuora
October 2018link
For the following warehouses, Fivetran now drops the primary_key
field from existing tables in your warehouse if there is a primary_key
coming in from your data source:
- MySQL
- PostgreSQL
- SQL Server
- Redshift
We have clarified the wording of the rescheduled sync notification message in your Sync History.
May 2018link
For logical replication mode, we have switched to a different logical decoding plugin that consumes significantly less disk and memory resources on the database instance.
We can now correctly parse PostgreSQL array data types with escaped characters.