Farewell, Timestream: How (and Why) to Migrate Before It’s Too Late

As of June 20, 2025, AWS has closed the door on new users of Amazon Timestream for LiveAnalytics. While existing users aren’t immediately affected, new AWS accounts can no longer create Timestream databases.

If you’ve used AWS services long enough, you know what this probably means. No new users means no new investment. No new features. And, eventually, end of support. This announcement marks the sunset clock quietly starting to tick for Timestream users.

In this post, we will walk through what this change means, the two flavors of Timestream that exist today, why migrating to Timestream for InfluxDB isn’t as attractive as it might seem, and how you can move to something much more powerful and future-proof: Tiger Postgres running on Tiger Cloud (creators of TimescaleDB).

The Two Shades of Amazon Timestream

This announcement applies specifically to Amazon Timestream for LiveAnalytics, the original engine launched by AWS in 2020 (and at the time, simply called “Timestream”). Today, however, there are two distinct products carrying the Timestream name, each with different architectures and capabilities.

Timestream for LiveAnalytics is the orginal product. It was AWS’s in-house, serverless time-series engine with a SQL-adjacent query language, automatic tiering, and storage classes (memory vs magnetic). It served metric pipelines very well (especially high-ingest, high-cardinality use cases like IOT), but over time, received limited feature updates.

Timestream for InfluxDB (launched March 2024)  is a fully managed, non-serverless wrapper around InfluxDB OSS 2.x. It supports InfluxQL and Flux, integrates with other Influx products like Telegraf, and is optimized for telemetry and observability use cases with simple schemas.

While both are branded under "Timestream," they are entirely separate products—with different query languages, engines, and operational models. There's no built-in migration path between them, which has created confusion for some teams.

Why Not Migrate to Timestream for InfluxDB?

If you're already deep in AWS and looking for the path of least resistance, Timestream for InfluxDB might seem like the logical next step. It's managed. It supports open-source tooling. It even has a familiar name.

But dig deeper, and the problems become clearer.

Timestream for InfluxDB is based on InfluxDB OSS 2.x, a version that's already been superseded by Influx 3.0. It’s feature-frozen, with no planned improvements or public roadmap. The newer version isn’t just a feature upgrade either, 3.0 was a full engine rewrite in a different language (Rust), with a new storage format and API. Choosing Influx 2.x today is like writing a new application in Python 2.7.

And it gets worse: Influx has historically made life difficult for developers trying to build serious applications. Across its lifecycle, the platform has suffered from:

• Too many incompatible engines (1.x, 2.x, 3.0), each with different storage, APIs, and performance profiles.
• Too many query languages: InfluxQL (a legacy SQL-like language), Flux (a legacy functional which is usually thought of as overcomplicated and too much of a paradigm shift), and now a new (limited) SQL variant in 3.0 (not available in OSS).
• No real relational model: no support for joins, normalized data, or rich metadata relationships.
• Fragmented roadmap: OSS and Cloud versions have diverged heavily, with major features only appearing in the closed-source platform.

If all you want is to ingest and graph simple telemetry metrics Influx might work. But if you need to correlate data, build application dashboards with real context, run complex analytics, or power real-time analytics you're going to hit walls.

And let’s not forget: migration isn’t free. You'll need to:

• Rewrite queries into InfluxQL or Flux (both of which are dead languages).
• Adapt your schema to Influx’s tag/field model.
• Learn the limitations of an outdated engine with no future roadmap.

It might seem easy because it's managed by AWS, but in reality you’re settling for a probable short-term patch, not a long-term solution.

TimescaleDB and Tiger Cloud: The Migration Timestream Needed

TimescaleDB, the open-source engine at the heart of our stack, takes a fundamentally different approach to both Timestream products. Rather than building a time-series database from scratch, we chose to extend PostgreSQL (the most trusted, extensible relational database in the world) and layer in blazing fast time-series support.

You get the best of both worlds:

• SQL that actually works (including the features Timestream left out, like DELETE, UPDATE, and schema evolution).
• A relational model that lets you join time-series data with business logic and metadata, cleanly and powerfully.
• Massive ingest performance and low-latency analytical queries, even across billions of rows.
• A massive, vibrant ecosystem that’s open, stable, and backed by decades of Postgres innovation.

Real-Time Analytics on Time Series Data

TimescaleDB goes far beyond just storing timestamped data. It’s a full analytical engine for metrics, events, measurements, and real-time analytics, built to handle time-series data alongside the rich relational and metadata models your application already uses.

• Hypertables automatically partition your data by time, giving you operational simplicity without sacrificing performance or flexibility. Recent data lives in a fast rowstore format for point inserts and updates, while older data is seamlessly compressed into a columnar layout. This hybrid format reduces storage by up to 95% and dramatically accelerates analytical queries, all without changing how you query your data.
• Continuous aggregates let you precompute common rollups—like hourly averages or daily counts—without building external batch jobs. They update automatically as new data arrives, so your dashboards stay fresh, and your queries stay fast.
• Hyperfunctions provide a native SQL toolkit for time-series analysis. You can compute things like time-weighted averages, rate of change, percentiles, counter resets, and gap-filling—all without writing custom logic in your app layer. These are the features Timestream users often had to hack together manually—now available as simple SQL.
• Time-series query optimizations are baked in. Native time partition pruning, SkipScan indexes, min/max exclusion, bloom filters, and vectorized execution mean that even billion-row datasets return results in milliseconds. 

And because all of this is built on PostgreSQL, you get a full relational toolbox out of the gate: SQL that works, joins that scale, JSONB support, CTEs, triggers, stored procedures, and all the extensions and integrations of the Postgres ecosystem.

Tiger Cloud: Built for Devs, Not Database Admins

If TimescaleDB gives you the power Timestream always lacked, Tiger Cloud gives you the ease of use. It’s a fully managed platform that feels just as seamless as an AWS-native service, but built for developers, not ops teams. No infrastructure to wire up. No guesswork around provisioning. Just spin up a service, connect your app, and ship.

• Runs where you already do. Tiger Cloud runs in AWS regions, right alongside your other workloads. It integrates directly with AWS S3 for ingest, minimizes latency across services, and fits naturally into existing cloud architectures.
• Decoupled storage and compute. Storage automatically expands and shrinks with your workload, removing allocation guesswork. Compute can be scaled up or down depending on your analytics requirements.
• Write and read isolation. Read replicas can be used to separate ingest and query workloads. You can run real-time dashboards, anomaly detection, or BI queries without interrupting ingestion pipelines or slowing things down.
• Tiered storage to reduce costs. Recent data stays hot in the rowstore, older data is compressed into columnar format, and even colder data moves to S3-backed object storage, all inside a single hypertable. No query rewrites, no data migrations, no operational headaches.
• Native observability. With Tiger Insights, every query is tracked in real time,latency, planning time, rows read, I/O behavior, cache hits. You can spot performance regressions or diagnose issues without touching your app or adding extra tooling.
• Built-in reliability. Tiger Cloud supports multi-AZ high availability, automatic failover, continuous backups, and point-in-time recovery, because if it’s going to be your system of record, it needs to be resilient by default.

Tiger Cloud is what Timestream could have been: easy to start, fast to scale, and powerful enough to handle real-time analytics without vendor lock-in. It’s the best of Postgres and TimescaleDB, extended for the cloud, operationalized, and ready to run in production today. Unlike the Influx variant, we also offer full support from the team that built the product, not just the team that runs it.

AWS and TigerData, Better Together

By pairing TigerData with AWS’s ecosystem, you get the best of both worlds: the power of PostgreSQL-native time-series analytics plus the convenience and reliability of a fully managed service.

Tiger Cloud is available today through the AWS Marketplace and is an AWS Partner ISV Accelerate offering, so you can deploy it in your favorite region and get consolidated billing. You can continue to use the AWS services you rely on (S3, Lambda, CloudWatch, VPCs, and more) while gaining TimescaleDB's hypertables, columnstore, continuous aggregates, and hyperfunctions. Tiger Cloud feels just like any other operationally ready AWS database, but combines relational and time-series superpowers under the hood.

Migration Steps for Tiger Cloud

If you’re ready to move off Timestream, here’s how to do it as smoothly as possible:

1. Export your data from Timestream

Use the UNLOAD command to dump Timestream data to S3:

UNLOAD (
  SELECT * FROM yourDB.yourTable
)
TO 's3://your-s3-bucket/'
WITH (
  include_header = 'true',
  max_file_size = '900MB'
);

• Each UNLOAD will be split into multiple files smaller than 1GB
• Each UNLOAD is capped at 73 GB, so you’ll want to batch large datasets by time window. 
• You can exclude or rename specific fields in the SQL if you want to make schema changes

2. Spin up an instance in Tiger Cloud

Sign up for Tiger Cloud (free for 30 days without a credit card), create a real-time analytics service, and you’ll be up and running in minutes.

3. Import your data from S3

Use the Livesync for S3 tool (available under the Actions menu for your service), which will monitor a bucket and migrate any S3 files found to a hypertable on the Tiger Postgres service. 

When you configure your import you’ll follow these steps:

1. Choose your S3 bucket, and your AWS authentication method.
2. Define your files to sync using a glob pattern, and remember to set “Skip header”
3. Check and correct column names and data-types if needed. Make sure to set your timestamp column’s type to timestamptz and enable the “Hypertable partition” slider.
4. Set your polling interval and click “Enable Livesync”.

If you’re only importing a one-off snapshot then you can delete the Livesync when you’re done. For a detailed walkthrough of setting this up check out this blog.

You’re up and running (but if you get stuck please reach out to support, they’d love to help).

Don’t Wait for the Lights to Go Out

While Timestream may still be running, it's future is less certain. You could move to InfluxDB under the Timestream banner, but you’ll be trading away SQL, relational power, and long-term stability for a managed service that’s already frozen in time.

With TimescaleDB on Tiger Cloud in AWS, you get:

• A future-proof foundation built on PostgreSQL
• Real time-series performance at scale, backed by features like hypertables, compression, continuous aggregates, and hyperfunctions.
• Turnkey management that feels as seamless as any AWS service, automatic scaling, tiered storage, built-in observability, and enterprise-grade reliability.

Sign up for Tiger Cloud today and give your migration a go!