Migrate your data to Timescale

Note

Migration assistance is included with Timescale's support service. If you would like help understanding your options, please reach out to our support.

You can open a support request directly from the Timescale console, or by email to [email protected].

There are a number of different ways to migrate your data to Timescale. Which option you choose depends on a few different factors, the most important of which are:

• How much downtime you can afford (minutes, or hours?)
• How much data you are migrating (megabytes, or terabytes?)
• Where you are migrating your data from (PostgreSQL, TimescaleDB, Influx, or MySQL?)

Below are the different migration options we offer. You can choose the one that best suits your requirements:

If you are using PostgreSQL or TimescaleDB and can afford to take your application offline for a few hours, the simplest option is to migrate data from another database into Timescale using PostgreSQL's pg_dump and pg_restore commands.

You can also use these tools to migrate your data from Managed Service for TimescaleDB, from a self-hosted TimescaleDB instance, or from another PostgreSQL database, including Amazon RDS.

If you are looking for a low-downtime alternative (with downtime on the order of minutes), you can choose one of our low downtime migration offerings:

1. Live migration
2. Dual-write and backfill

Live migration is Timescale's packaging of Postgres' logical replication functionality, which leverages the excellent pgcopydb project from the Postgres community. Live migration is an end-to-end solution which copies the database schema and data, and then replicates changes in real-time from one database to the other.

Dual-write and backfill is a method to write from your application to two databases at once, and gives tooling and guidance to move your existing data from the one database to the other. It is specifically catered for, and relies on, your data being predominantly append-only time-series data. As such, it comes with some caveats and prerequisites which live migration does not (dual-write and backfill does not support executing UPDATE or DELETE statements on your data). Additionally, it requires you to make changes to the ingest pipeline of your application.

We recommend using live migration if modifying your application logic to perform dual writes is a significant effort on your end, or if you are using UPDATE and DELETE statements on your uncompressed time-series data (live migration does not support replicating INSERT/UPDATE/DELETE statements on compressed data). If your application is writing more than 20'000 rows per second, you should use dual-write and backfill instead.

We recommend using dual-write and backfill if modifying your ingest pipeline is not an issue, and if you want to evaluate your existing solution side-by-side with the new Timescale-based solution. Dual-write and backfill is the only low-downtime solution if you're migrating from a database other than PostgreSQL.

If you're migrating from something other than PostgreSQL, and don't want to use above listed migration options, then the easiest way to move your data to Timescale is by exporting the data from your existing database as a .csv file, and importing it with timescaledb-parallel-copy.

For other ingestion methods, see the data ingest section.

For a detailed, step-by-step guide on migrating from various databases to Timescale, please refer to the migration playbooks.

If you encounter any difficulties while migrating, consult the troubleshooting documentation, open a support request, or take your issue to the #migration channel in the community slack, where the developers of this migration method are there to help.

You can open a support request directly from the Timescale console, or by email to [email protected].