By Carlo Mencarelli
By Tiger Data Team
Updated at Mar 27, 2026
Originally published on July 3, 2024
Amazon Timestream for LiveAnalytics closed to new customers in June 2025. This page covers your current options.
Amazon Timestream for LiveAnalytics is no longer available to new customers. If you're evaluating AWS time series database options or planning a migration from LiveAnalytics, this guide covers the four most relevant paths: Timestream for InfluxDB, Tiger Cloud, Amazon Aurora PostgreSQL, and Amazon RDS PostgreSQL.
Tiger Cloud is one of the options covered here, and Tiger Data (the company behind this guide) builds it. We've been transparent about that throughout so you can weigh our perspective accordingly. The tradeoffs for each option are documented with the same level of detail.
Amazon Timestream was always two separate products, and the distinction matters:
Timestream for LiveAnalytics was the original product, launched in 2020. AWS closed it to new customers on June 20, 2025. Existing customers can continue using it, add users under the same payer account, and receive security and availability maintenance. AWS has not announced an end-of-life date for existing customers.
Timestream for InfluxDB launched in 2023 and remains AWS's active, recommended product for new Timestream workloads. In October 2025, AWS and InfluxData announced InfluxDB 3 Core and Enterprise support on this managed service, addressing earlier concerns about the 2.x engine's feature freeze.
While AWS has not officially labeled this a deprecation, the effect is the same for teams evaluating new infrastructure: LiveAnalytics is closed, receives no new features, and the recommended replacement is a different product entirely.
If you're an existing LiveAnalytics customer, you're not being forced to migrate today. But you should understand your options before planning new workloads or making scaling decisions.
Before evaluating alternatives, it helps to establish what matters. Any time-series database you adopt should deliver on these properties:
Scalability - Can it handle your data volume as it grows? Time-series workloads compound. What works at 1 TB will not necessarily work at 50 TB without rearchitecting.
Maintainability - How much engineering time does the system consume? Partition management, index tuning, schema migrations, and operational overhead add up fast.
Reliability - What happens during failures? For production telemetry and monitoring workloads, downtime means blind spots.
Usability - Can your team query and operate it without learning an entirely new stack? Query language familiarity, tooling compatibility, and ecosystem support matter.
Cost predictability - This is the one LiveAnalytics users learned the hard way. Timestream's scan-based billing model meant that analytical queries could generate unexpected costs. Any replacement should give you a billing model where you can forecast monthly spend without surprises.
The rest of this guide covers four paths in detail:
Amazon Timestream for InfluxDB - AWS's recommended path for workloads requiring single-digit millisecond query latency. Stays within AWS managed services.
Tiger Cloud - A PostgreSQL-native managed time-series database service. Full SQL compatibility without learning a new query language. Runs outside the AWS managed service boundary.
Amazon Aurora PostgreSQL - AWS's enterprise-grade managed relational database. Recommended by AWS for complex SQL workloads migrating off LiveAnalytics.
Amazon RDS PostgreSQL - AWS's standard managed PostgreSQL offering. Simpler to provision and lower cost than Aurora for most workloads.
ClickHouse, VictoriaMetrics, and QuestDB are alternatives some teams evaluate. The FAQ addresses these. For a broader managed database comparison, see our best managed time-series databases guide. This page focuses on the four paths most relevant to engineers coming from a Timestream workload.
Timestream for InfluxDB is AWS's managed offering built on the InfluxDB engine. It is the path AWS explicitly recommends for engineers who need single-digit millisecond query latency and are moving off LiveAnalytics.
As of October 2025, Timestream for InfluxDB supports InfluxDB 3 Core and Enterprise in addition to the original InfluxDB 2.x support. This is a meaningful update. The feature-freeze concern about the 2.x engine, which was accurate before October 2025, is now partially addressed. Teams should verify which InfluxDB version their provisioned instance runs.
Query languages supported: InfluxQL and Flux for InfluxDB 2.x deployments. SQL is available in InfluxDB 3-based deployments. Engineers migrating from LiveAnalytics (which used Timestream Query Language) will need to rewrite queries regardless of which InfluxDB version they choose.
Timestream for InfluxDB uses a managed EC2 wrapper model. You pay for compute and storage rather than the scan-based model LiveAnalytics used. For some workloads (low-traffic, multi-table, bursty analytical queries) this can be more expensive than LiveAnalytics was. For high-cardinality, continuous ingest workloads, the cost is more predictable.
See the AWS Timestream for InfluxDB pricing page for current rates.
This is a critical evaluation gate. AWS recommends the migration path from LiveAnalytics to Timestream for InfluxDB only for workloads with fewer than 10 million unique series keys (cardinality). Teams should audit their Timestream usage before committing to this path.
If your cardinality exceeds 10 million series on InfluxDB 2.x instances, performance degrades significantly. InfluxDB 3 Enterprise claims unlimited cardinality support, but teams should verify this against their specific workload before committing.
AWS documents a 4-step migration path from LiveAnalytics to Timestream for InfluxDB:
Unload LiveAnalytics data to Amazon S3
Transform data schema using Amazon Athena
Ingest transformed data into Timestream for InfluxDB
Validate data integrity and update application endpoints
AWS provides no built-in migration tooling. This is a manual engineering project. Budget time and resources accordingly.
If your Grafana dashboards use Timestream Query Language natively, they will need to be rebuilt for InfluxQL, Flux, or SQL (InfluxDB 3).
Choose this path if your workload requires single-digit millisecond query latency, your cardinality is under 10 million series, your team is comfortable with InfluxQL/Flux/SQL (InfluxDB 3), and staying within AWS managed services is a hard requirement.
Tiger Cloud is Tiger Data's fully managed cloud service, built on PostgreSQL with the TimescaleDB extension. Engineers who already know SQL don't need to learn a new query language.
TimescaleDB is the open-source project. Tiger Cloud is the managed service. This distinction matters for engineers evaluating managed versus self-hosted options.
Key capabilities relevant to former Timestream users:
Hypertables - Automatic time-based partitioning. No manual partition management as data grows.
Continuous aggregates - Precomputed rollups with automatic refresh. Dashboards stay fast without batch jobs.
Columnstore compression - Up to 95% storage reduction based on customer deployments
Native pgvector support - For teams adding ML/AI workloads alongside time-series data.
Tiger Cloud runs outside AWS's managed service boundary. It is not RDS or Aurora. Engineers with hard requirements to stay within AWS's managed service ecosystem should note this tradeoff.
Tiger Data's benchmark blog post documented 6,000x higher inserts, 5-175x faster queries, and 150-220x lower cost versus Timestream LiveAnalytics. These benchmarks used TimescaleDB 1.7.4 versus Timestream LiveAnalytics in 2020. Technology versions have changed since then.
The directional conclusion - that a PostgreSQL-native time-series database outperforms Timestream's scan-based architecture for most workloads - is consistent with community reports. Torus, a Tiger Data customer that migrated from Timestream, reported response times dropping from 800ms to 70ms.
From Timestream LiveAnalytics: export data via the Unload to S3 path, then ingest into Tiger Cloud using standard PostgreSQL COPY or a streaming pipeline. Query language rewrite is required (Timestream Query Language to SQL). Grafana users can point dashboards to Tiger Cloud's PostgreSQL endpoint with minimal connector changes.
For a full walkthrough, see the migration guide from Timestream to Tiger Cloud.
Choose Tiger Cloud if your team values SQL compatibility and doesn't want to learn InfluxQL or Flux, your cardinality exceeds 10 million series (which disqualifies the InfluxDB path), you want a managed service without managing EC2/Aurora instances, or you're adding vector/ML capabilities alongside time-series data.
Aurora PostgreSQL is AWS's enterprise-grade managed relational database service. It is one of the two AWS-native options AWS's own documentation recommends for engineers migrating off LiveAnalytics who need complex SQL and relational capabilities.
Aurora is not natively a time-series database. It does not have hypertables, automatic time-based partitioning, or time-series-specific compression. Engineers can implement time-series patterns (time-based partitioning, rollup tables) in Aurora manually or using the TimescaleDB extension on Aurora.
Note: TimescaleDB is available as a PostgreSQL extension and can be installed on Aurora. This gives Aurora users time-series capabilities but requires self-management of that extension layer.
Choose Aurora if you need tight AWS ecosystem integration, your workload has complex relational joins alongside time-series queries, you have existing AWS database expertise and tooling, and managed infrastructure within AWS is a hard requirement.
RDS PostgreSQL is AWS's standard managed PostgreSQL offering. It is simpler to provision and manage than Aurora, with a lower performance ceiling and lower cost for most workloads.
Like Aurora, RDS is not natively time-series optimized. The TimescaleDB extension is available on RDS PostgreSQL, providing time-series capabilities within the RDS environment.
AWS's migration documentation covers the RDS path as an option for engineers moving from LiveAnalytics who want relational SQL capabilities.
Choose RDS if you want simple AWS-managed PostgreSQL without Aurora's complexity and cost, your workload does not require Aurora's performance ceiling, and you want to optionally add TimescaleDB as an extension.
Choose... | If... |
Timestream for InfluxDB | Single-digit ms latency required, cardinality under 10M series, team knows InfluxQL/Flux, must stay in AWS managed services |
Tiger Cloud | SQL-native team, cardinality over 10M series, want managed TSDB outside AWS boundaries, adding ML/AI workloads (pgvector), want up to 95% compression |
Amazon Aurora PostgreSQL | Hard AWS managed services requirement, complex relational + time-series mixed workloads, existing AWS database team |
Amazon RDS PostgreSQL | Simple AWS-managed PostgreSQL, cost-sensitive, want optional TimescaleDB extension without Aurora overhead |
For teams that are not forced to migrate: staying on LiveAnalytics is a valid near-term choice. AWS has not announced a shutdown date. But new workloads should not be built on LiveAnalytics. It is closed to new customers and receives no new feature development.
These are the cross-cutting concerns engineers face regardless of which path they choose. The questions here surface repeatedly in AWS re:Post migration threads and community discussion.
Timestream Query Language (TQL) is proprietary. Migrating to any of the four options requires query rewrites. There is no automated translation tool. Budget engineering time for this.
For SQL-compatible targets (Tiger Cloud, Aurora, RDS): engineers familiar with standard SQL will find query rewrites relatively direct, especially for aggregations and window functions.
For InfluxQL/Flux targets (Timestream for InfluxDB): this requires learning the InfluxDB query model, which differs significantly from SQL. InfluxDB 3 deployments support SQL, which reduces this friction.
Grafana supports data source connectors for both InfluxDB and PostgreSQL. Teams migrating dashboards will need to update data source configurations and potentially rewrite some queries in panel definitions.
The PostgreSQL connector (for Tiger Cloud, Aurora, RDS) is widely supported and stable. The InfluxDB connector supports InfluxQL and Flux.
AWS provides an Unload to S3 export path for LiveAnalytics data. This is the standard starting point for any migration. Plan for S3 storage costs during the migration window.
There is no streaming migration path. This is a batch export and re-ingest process.
LiveAnalytics used scan-based billing. All four replacement options use different billing models (compute + storage, request units, provisioned capacity). Cost comparison requires workload-specific modeling. Do not assume any option is cheaper without running numbers against your actual query patterns and data volume.
For rough guidance: Tiger Data's published benchmarks suggest PostgreSQL-native options (Tiger Cloud, Aurora with TimescaleDB) tend to have lower cost per query for analytical workloads than scan-based databases. Timestream for InfluxDB's managed EC2 model can be more expensive for low-traffic or bursty workloads.
Timestream for LiveAnalytics closed to new customers on June 20, 2025, but existing customers are not being shut down. AWS has not announced an end-of-life date. Existing customers can continue using LiveAnalytics, add users under the same payer account, and receive security and availability updates. New workloads should not be built on LiveAnalytics.
AWS recommends Timestream for InfluxDB for workloads requiring real-time query performance (single-digit ms), and Amazon Aurora or RDS PostgreSQL for workloads requiring complex SQL and relational capabilities. These recommendations are from AWS's own migration documentation. AWS does not reference third-party options like Tiger Cloud in its official guidance.
Timestream for InfluxDB is a managed AWS service that runs the InfluxDB engine on managed EC2 infrastructure. It supports InfluxDB 2.x (InfluxQL and Flux) and, as of October 2025, InfluxDB 3 Core and Enterprise (which adds SQL support). It is not the same as a self-hosted InfluxDB deployment. It is a managed wrapper. Cost and capability differ from both InfluxDB Cloud (InfluxData's own managed offering) and self-managed InfluxDB.
AWS recommends Timestream for InfluxDB for workloads with fewer than 10 million unique series keys (cardinality). If your Timestream LiveAnalytics workload exceeds this threshold, evaluate PostgreSQL-native alternatives (Tiger Cloud, Aurora PostgreSQL, RDS PostgreSQL) rather than the InfluxDB migration path.
Yes, if you migrate to Tiger Cloud, Amazon Aurora PostgreSQL, or Amazon RDS PostgreSQL. These are all SQL-native. Timestream for InfluxDB supports SQL only on InfluxDB 3 deployments. InfluxDB 2.x-based deployments use InfluxQL and Flux.
AWS provides an Unload to S3 export feature for LiveAnalytics data. Data is exported in CSV or Parquet format to an S3 bucket. From there, you can transform and load into your target database. There is no automated migration tool or streaming migration path. Plan for this as an engineering project with appropriate time and cost budgets.
Not without updates. If your Grafana dashboards use a Timestream data source connector, you will need to reconfigure them to point to your new database. Tiger Cloud and PostgreSQL-based options use Grafana's standard PostgreSQL connector. Timestream for InfluxDB uses the InfluxDB connector. Panel-level queries will also need to be rewritten in the target query language.
No. Tiger Cloud is Tiger Data's managed cloud service. It is not part of AWS's managed services portfolio (not RDS, not Aurora). It runs on its own cloud infrastructure. You will not see it in the AWS Console, and AWS support does not cover it. Engineers with a hard requirement to stay within AWS managed services should evaluate Timestream for InfluxDB, Aurora, or RDS instead.
Before October 2025, Timestream for InfluxDB ran only InfluxDB 2.x, which had not received new feature development. In October 2025, AWS and InfluxData announced support for InfluxDB 3 Core and Enterprise on Timestream for InfluxDB. This resolves the feature-freeze concern for teams that provision InfluxDB 3-based instances. Verify which version your instance is running. Provisioning process and pricing may differ between versions.
Tiger Cloud is built on PostgreSQL with the TimescaleDB extension. InfluxDB (including Timestream for InfluxDB) uses a purpose-built time-series engine. The primary trade-offs: Tiger Cloud offers full SQL compatibility, JOIN support, relational modeling, and native vector support (pgvector). InfluxDB offers single-digit ms query latency optimized for high-cardinality IoT and monitoring workloads. See the InfluxDB alternatives comparison for a deeper analysis.
Yes. ClickHouse, VictoriaMetrics, and QuestDB are databases some engineers evaluate as Timestream replacements, particularly for high-throughput analytics workloads. This page focuses on the four options most relevant to teams migrating from a Timestream workload in an AWS-adjacent environment. For a broader comparison, see the best time-series databases compared.