You have chosen to migrate or sync your data to Timescale Cloud, thank you.
Depending on the amount of data you need to migrate, and the amount of downtime you can afford. Timescale offers the following ways to migrate your data:
| Migration strategy | Use when | Downtime requirements |
|---|---|---|
| Migrate with downtime | Use pg_dump and pg_restore to migrate when you can afford downtime. | Some downtime |
| Live migration | Simplified end-to-end migration with almost zero downtime. | Minimal downtime |
| Dual-write and backfill | Append-only data, heavy insert workload (~20,000 inserts per second) when modifying your ingestion pipeline is not an issue. | Minimal downtime |
All strategies work to migrate from PostgreSQL, TimescaleDB, AWS RDS, and Managed Service for Timescale. Migration
assistance is included with Timescale support. If you encounter any difficulties while migrating your data,
consult the troubleshooting page, open a support request, or take your issue to the #migration channel
in the community slack
, 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 support@timescale.com.
If you're migrating your data from another source database type, best practice is export the data from your source database as
a .csv file, then import to your Timescale Cloud Service using timescaledb-parallel-copy. For other ingestion methods,
see Ingest data from other sources.
You use livesync to synchronize all or some of your data to your Timescale Cloud service in real-time. You run livesync continuously, using your data as a primary database and your Timescale Cloud service as a logical replica. This enables you to leverage Timescale Cloud’s real-time analytics capabilities on your replica data.
| livesync options | Downtime requirements |
|---|---|
| livesync for PostgreSQL | None |
| livesync for S3 | None |
Keywords
Found an issue on this page?Report an issue or Edit this page in GitHub.