By Tiger Data team
Updated at May 28, 2026
When AWS closed Timestream LiveAnalytics to new customers in June 2025, engineers were pointed toward Timestream for InfluxDB as the managed migration path. Many moved forward. Some then discovered a hard architectural limit: an AWS Timestream for InfluxDB alternative becomes necessary when your workload runs into the architectural limits of InfluxDB 3's storage engine — specifically, a hard cap of 500 measurements per database and 200 columns per measurement. This page covers how to determine whether you're in that situation and what your options are.
For a broader look at your options after Timestream LiveAnalytics, see our AWS Timestream alternatives after LiveAnalytics overview.
Timestream for InfluxDB is AWS's managed hosting service for InfluxDB, operating under the Timestream name. It is not a new database product. The underlying engine is InfluxDB, built by InfluxData. AWS manages the infrastructure; InfluxData provides the database software.
The version engineers get is InfluxDB 3, not 1.x or 2.x. This matters more than the version number suggests. InfluxDB 3 uses InfluxQL and SQL for queries, not the Flux functional language from InfluxDB 2.x. If your team ran InfluxDB 1.x or 2.x pipelines with Flux, those need to change before you can use this service. InfluxDB's history of breaking changes across major versions is well documented, and inheriting that complexity is a real migration consideration.
Pricing is instance-based plus storage, billed hourly through AWS. If your team is already running AWS infrastructure, it fits into existing billing without adding a new vendor relationship.
The rest of this page covers when Timestream for InfluxDB is the right call, and when its schema structure limits turn it into the wrong one.
Timestream for InfluxDB is a solid fit for specific workload profiles.
Workloads with moderate schema complexity. Workloads with schemas that stay within InfluxDB 3's structural limits - fewer than 500 distinct measurements and fewer than 200 columns (tags + fields + time) per measurement - are well within the comfortable operating range for Timestream for InfluxDB."
Teams already running InfluxDB. If your team runs InfluxDB 1.x or 2.x and wants to move to managed infrastructure without rethinking the whole stack, Timestream for InfluxDB is the lowest-friction path. The InfluxQL compatibility in InfluxDB 3 makes the query layer familiar, even if the version migration requires some work.
AWS-native infrastructure teams. If the rest of your stack runs on AWS (Lambda, IoT Core, S3, CloudWatch), staying on a managed AWS service is architecturally simpler. No new billing relationship, no new vendor to evaluate, no network topology to rethink.
Existing Telegraf pipelines. Telegraf's InfluxDB output plugin writes directly to Timestream for InfluxDB. If your collection pipeline runs Telegraf today, the ingest path is unchanged. Only the destination endpoint changes.
These advantages are real. However, they disappear when schema complexity pushes against InfluxDB 3's structural limits. Here's why.
InfluxDB Cloud Serverless, which powers Timestream for InfluxDB, enforces two hard storage-level limits: a maximum of 500 tables (measurements) per database, and a maximum of 200 columns per table (where columns include time, all tag keys, and all field keys). These are architectural constraints, not AWS configuration settings. AWS cannot raise them without InfluxData's involvement.
Why Timestream migrants hit it. Timestream LiveAnalytics used a table-dimension-measure model with no fixed cap on the number of tables or columns. Engineers running industrial sensor networks, connected vehicle fleets, or energy telemetry grids often designed wide schemas — many measurements with many fields. When they migrate to Timestream for InfluxDB, the 500-table and 200-column limits show up as ceilings they were never bumping against before. InfluxData's schema design guidance recommends designing around these limits from the start.
A concrete example. Consider an industrial deployment that tracks 600 distinct sensor types, each as its own measurement. That deployment hits the 500-table limit before onboarding all sensor types. Alternatively, consider a single measurement tracking 180 tag/field combinations per device. Adding a firmware version tag and two new diagnostic fields pushes past the 200-column limit, causing write failures.
How you know if you're in this category. If your Timestream LiveAnalytics deployment used more than 400 distinct table types, or if any single table tracked more than 150 dimensions and measures combined, you are likely to hit the InfluxDB 3 schema limits. To estimate your exposure: count distinct measurement names in your schema (must stay under 500), and count the total number of tag keys plus field keys in your widest measurement (must stay under 199, leaving one column for time).
What happens when you exceed it. The symptom is a write failure with an explicit error message: InfluxDB returns an HTTP error stating the table or column limit has been reached. The limits are architectural, not operational. Adding instances does not fix them.
Query language. Timestream LiveAnalytics used a SQL-like query language. Timestream for InfluxDB uses InfluxQL or SQL (via Apache DataFusion). InfluxQL is SQL-adjacent and learnable, but teams that built dashboards on Timestream's SQL dialect will need to rewrite queries. That is real scope on top of the data migration itself.
You can dive deeper into how Tiger Data and InfluxDB handle high-cardinality data differently.
Dimension | Timestream for InfluxDB | Tiger Cloud |
Query language | InfluxQL + SQL (InfluxDB 3) | PostgreSQL SQL (full standard SQL) |
Schema limits | 500 tables/database; 200 columns/table (hard limits, InfluxDB 3) | No fixed table or column limits (relational model, schema defined by user) |
Data model | Tags + fields (InfluxDB line protocol) | Relational hypertables (PostgreSQL tables, partitioned by time) |
Cloud portability | AWS-only | AWS, Azure, GCP |
Pricing model | Instance + storage (hourly, AWS markup) | Compute + storage (Tiger Cloud) |
Grafana integration | Requires Timestream for InfluxDB plugin | Native PostgreSQL data source (no plugin required) |
PostgreSQL ecosystem compatibility | No | Full (extensions, ORMs, BI tools) |
Version stability | InfluxDB 3 (breaking changes from 1.x/2.x) | PostgreSQL (decades of application compatibility) |
Retention and downsampling | Retention policies (InfluxDB-style) | Continuous aggregates + data retention policies |
Compression | InfluxDB columnar compression | Columnstore compression (up to 95% in internal benchmarks) |
The table reflects documented architecture. If your team runs Telegraf-native pipelines and your schema stays well within the 500-table and 200-column limits, Timestream for InfluxDB is a simpler migration. If your schema pushes those limits, or you want to stop depending on a single cloud provider's managed service, the comparison shifts.
Tiger Cloud is built on PostgreSQL. For Timestream migrants, a few capabilities directly address the gaps that Timestream for InfluxDB can't fill.
SQL continuity. Tiger Cloud uses PostgreSQL SQL. If your team wrote Timestream queries in SQL, you write Tiger Cloud queries in SQL. No InfluxQL. No Flux. Standard PostgreSQL clients, drivers, and ORMs work as-is.
Hypertables. A hypertable is a PostgreSQL table with automatic time-based partitioning. You create one with a single command:
SELECT create_hypertable('sensor_readings', 'time');
After that, you use it like any other PostgreSQL table, because it is one. Time-based partitioning happens automatically under the hood. Queries stay bounded as data volume grows.
Continuous aggregates. Continuous aggregates are materialized views that Tiger Data updates incrementally as new data arrives. Instead of re-aggregating billions of rows for every dashboard query, the aggregation is pre-computed and refreshed in the background. This is the Tiger Cloud answer to Timestream's scheduled query aggregation features, without the proprietary query syntax.
Performance after migration. Engineers who have made the switch from Timestream report concrete results. One customer engineer at Torus noted: "We were sitting at about 800 milliseconds on average for our response time with Timestream, and switching over to Timescale we're now like 70 milliseconds. So far Timescale has scaled significantly better than Timestream. We thought we would need a bigger instance to run our production... but we're just running it on one CPU and it's cruising."
Columnstore compression. Tiger Cloud's columnstore stores column data contiguously on disk, achieving 90 to 95% compression on time-series data in internal benchmarks. For teams managing storage costs on Timestream's per-instance billing model, that kind of compression changes the cost picture.
No fixed schema limits. PostgreSQL's relational model does not impose a cap on the number of tables or columns in a database. A deployment that would exceed InfluxDB 3's 500-table or 200-column-per-table limits runs on Tiger Cloud without schema restructuring. You define the schema; the database doesn't constrain it.
Learn more about handling high-cardinality data in PostgreSQL.
Multi-cloud deployment. Tiger Cloud runs on AWS, Azure, and GCP. For engineers who distrust single-cloud managed services after experiencing a deprecation, this is a structural argument. The LiveAnalytics shutdown is a data point about the risk of depending on a single provider's managed database product as a core service.
Octave migration. Octave, a cleantech company managing second-life EV batteries, migrated from AWS Timestream to Tiger Data. Their workload involved collecting and analyzing large volumes of sensor time-series data across a battery fleet. After migration, they achieved significant improvements in compression on historical data. The full story is in the Octave case study: migrating from AWS Timestream.
For a comparison of Tiger Cloud and InfluxDB at depth, see the TimescaleDB vs. InfluxDB deep dive and the later article at What InfluxDB Got Wrong.
Your schema uses fewer than 400 distinct measurements and no single measurement exceeds ~150 tag and field columns - well within the hard limits with headroom
Your team already runs Telegraf and InfluxDB 1.x/2.x, and the migration effort to InfluxDB 3 is acceptable
You are AWS-only by choice and have no plans to run workloads on other cloud providers
Your team does not need PostgreSQL ecosystem compatibility: no existing PostgreSQL ORMs, reporting tools, or applications
You want a single-vendor managed service inside AWS billing with no new vendor relationships
Your schema requires more than 400 distinct measurements, or any single measurement tracks more than ~150 tag and field columns.
Your team already knows SQL and does not want to learn InfluxQL or Flux
You need cloud portability: the ability to run on AWS today and move to Azure or GCP later without changing your database
You want PostgreSQL ecosystem compatibility: existing ORMs, BI tools (Tableau, Metabase, Redash), and PostgreSQL drivers work without modification
You are migrating from Timestream's SQL-like query language and want to preserve query logic without rewriting to InfluxQL
Your Grafana dashboards use the native PostgreSQL data source. Reconnecting to Tiger Cloud requires only changing the connection string, not installing a plugin
For a broader view of managed time-series database options, including how other alternatives compare, see best managed time-series databases in 2026.
For IoT-specific workload guidance, see best database for IoT in 2026.
The below is an overview (for the operational step-by-step, see migrating from AWS Timestream: step-by-step).
The high-level path:
Export historical data from your existing Timestream deployment to S3 using the UNLOAD command
Provision a Tiger Cloud instance on AWS, Azure, or GCP and create your hypertable schema, mapping Timestream's dimensions to PostgreSQL columns
Load historical data from S3 into Tiger Cloud using standard PostgreSQL COPY or Tiger Data's ingest tools
Reconnect your data sources: update Grafana to use the PostgreSQL data source pointing at Tiger Cloud; update application connection strings to the Tiger Cloud endpoint
Telegraf pipelines. Tiger Cloud accepts InfluxDB line protocol directly through its ingest endpoint. Telegraf pipelines can write to Tiger Cloud without modifying the collection agent configuration. Only the output destination changes.
Tiger Cloud has a free trial with no credit card required. Migration support is available for larger workloads.
AWS Timestream for InfluxDB is AWS's managed hosting service for InfluxDB 3, branded under the Timestream name. It is not a new database product. The underlying engine is InfluxDB, built by InfluxData. AWS manages the infrastructure; InfluxData provides the database software.
Two main reasons. First, schema structure limits: InfluxDB 3 enforces a hard cap of 500 measurements per database and 200 columns per measurement. Workloads that designed wide schemas against Timestream LiveAnalytics will hit these limits. Second, query language fragmentation: v2 uses InfluxQL or Flux, while v3 uses InfluxQL or SQL via Apache DataFusion. Teams migrating from Timestream LiveAnalytics, or between InfluxDB versions, face query rewrites either way.
InfluxDB 3, which powers Timestream for InfluxDB, does not have a series cardinality limit — tag value cardinality does not degrade performance. What it does have are hard schema limits: a maximum of 500 tables (measurements) per database, and a maximum of 200 columns per table (time + all tag keys + all field keys). To check your exposure: count distinct measurement names in your schema (must stay under 500), and count the total tag keys plus field keys in your widest measurement (must stay under 199).
No. Tiger Cloud is built on PostgreSQL, which uses a relational data model. PostgreSQL does not impose fixed limits on the number of tables or columns. A deployment that would exceed InfluxDB 3's 500-table or 200-column-per-table limits runs on Tiger Cloud without schema restructuring.
No. Tiger Cloud uses standard PostgreSQL SQL. If your team wrote queries against Timestream's SQL-like query language or writes queries in standard SQL today, those skills transfer directly. No InfluxQL, no Flux.
Yes, without a plugin. Grafana ships with a native PostgreSQL data source. Reconnecting your Grafana dashboards to Tiger Cloud requires changing the data source connection string. You do not need the Timestream for InfluxDB Grafana plugin or any third-party extension.
Tiger Cloud runs on AWS, Azure, and GCP. If you want to stay on AWS, you can. If you want multi-cloud flexibility, Tiger Cloud supports that without requiring application changes. You connect via a standard PostgreSQL connection string regardless of which cloud hosts the instance.
Telegraf can write to Tiger Cloud in two ways. If you use the PostgreSQL output plugin, it writes directly to Tiger Cloud as a standard PostgreSQL destination. Tiger Cloud also supports InfluxDB line protocol over its ingest endpoint, meaning Telegraf with the InfluxDB output plugin can write to Tiger Cloud without modifying the agent configuration. Only the endpoint URL changes.
There is no public announcement of deprecation for Timestream for InfluxDB at this time. However, the LiveAnalytics deprecation is a reasonable data point: AWS retired a managed database product with limited notice. Tiger Cloud is managed by Tiger Data, whose core business is this database. There is no product portfolio reason to deprecate it. This is a subjective risk factor, not a documented certainty, but it is one some engineers weigh when making long-term infrastructure decisions.
The mechanical steps (export from Timestream to S3, load into Tiger Cloud, reconnect data sources) can be completed in a day for smaller deployments. Larger workloads with custom applications, multiple Grafana dashboards, and significant historical data typically take 2 to 8 weeks including validation and cutover.
Timestream for InfluxDB is built on InfluxDB 3. This matters because InfluxDB 3 is not backward compatible with InfluxDB 1.x or 2.x in all scenarios. Teams running Telegraf pipelines written for InfluxDB 2.x may need to update their configurations. InfluxDB has a documented history of breaking changes across major versions. This is worth evaluating before committing to Timestream for InfluxDB as a migration target.