Amazon Timestream in 2026: LiveAnalytics vs Timestream for InfluxDB

Search for "AWS Timestream" in 2026 and you find two different products under one name. Amazon Timestream for LiveAnalytics is the original serverless engine, with its own SQL dialect, dimensions, and measures. Amazon Timestream for InfluxDB is managed open source InfluxDB, now offered as InfluxDB 2 instances and InfluxDB 3 clusters. Since 20 June 2025, LiveAnalytics has been closed to new customers, and teams already on it are asking whether to move, where to, and how. This guide covers its current status, the Timestream for InfluxDB options, data model and pricing differences, AWS's migration path, the alternatives, and a decision table.

Scope and review date: November 2026. This post covers Amazon Timestream for LiveAnalytics, Amazon Timestream for InfluxDB 2, and Amazon Timestream for InfluxDB 3 (Core and Enterprise editions). Commands, limits, and dates were checked against the Amazon Timestream Developer Guide, the AWS CLI reference, and the amazon-timestream-tools repository on 9 November 2026. They were not run in a lab, so rehearse them on a non-production account first. No prices are quoted; use the AWS pricing page for your Region.

What happened to Amazon Timestream for LiveAnalytics?

AWS's availability change notice says AWS closed new customer access to LiveAnalytics effective 20 June 2025. The same notice says the change does not affect running workloads, that existing customers with an active payer account can keep adding users and linked accounts, and that AWS continues to invest in security, availability, and performance for the service. It recommends that new customers evaluate Timestream for InfluxDB instead.

As of November 2026, the notice gives no end-of-support date, so a migration is a planning decision, not an emergency. The real constraint is organizational: a new AWS Organization, a carve-out into a new payer account, or an acquisition can leave a team unable to use the service in the new account.

# Inventory what you run on LiveAnalytics today
aws timestream-write list-databases --region us-east-1
aws timestream-write list-tables --database-name my_database --region us-east-1
aws timestream-write describe-table --database-name my_database \
    --table-name my_table --region us-east-1

Interpretation: describe-table returns each table's retention properties: how many hours data stays in the memory store and how many days in the magnetic store. Those two numbers tell you how much history a migration must move, and they are the first input to every target sizing exercise below.

What does Timestream for InfluxDB offer in 2026?

Timestream for InfluxDB now covers two engine generations. Both run in your VPC and are managed by AWS (provisioning, patching, and backups), with no host access.

InfluxDB 2. The developer guide describes it as the open source InfluxDB 2.x branch on a DB instance. Instance classes run from db.influx.medium (1 vCPU, 8 GiB) to db.influx.24xlarge (96 vCPU, 768 GiB). Storage is the Influx IOPS Included type in three tiers: 3,000, 12,000, and 16,000 IOPS. You can deploy single-AZ or with a Multi-AZ standby (WITH_MULTIAZ_STANDBY). Since February 2025, you can also build a read replica cluster. It uses InfluxData's licensed add-on, which you subscribe to through AWS Marketplace, and it replicates asynchronously to read-only replicas behind a -ro endpoint. The default port is 8086. AWS recommends staying under 10 million series per instance.

InfluxDB 3. AWS added InfluxDB 3 on 16 October 2025. It is a different engine: Apache Arrow in memory, DataFusion for queries, and Parquet files on Amazon S3 instead of the TSM engine. It comes in two editions:

• Core is single-node and has no compaction. The InfluxDB 3 FAQ positions it for recent data, typically around 3 days, and says query performance degrades as data ages.
• Enterprise adds compaction, historical query indexing, and multi-node clusters across Availability Zones. Since 16 March 2026, a cluster can have up to 15 nodes: 1 to 4 writer/reader nodes, 0 to 13 reader-only nodes, and one dedicated compactor.

InfluxDB 3 queries use SQL and InfluxQL, not Flux. The CLI reference gives 8181 as the default port for InfluxDB 3.

How do the pricing models differ?

This section compares billing units only. Prices change by Region and over time, so take current rates from the Amazon Timestream pricing page on the day you model costs.

The shapes differ more than the rates. LiveAnalytics costs follow how much you write, keep, and query. InfluxDB costs are mostly fixed by the nodes you run, busy or idle. Model both with your own volumes. AWS states that InfluxDB 3 object storage can cost up to 75% less than InfluxDB 2 for deployments over 16 TB; that is AWS's figure, not a measurement of your data.

# LiveAnalytics: metered ingestion bytes per day for one database
aws cloudwatch get-metric-statistics --namespace AWS/Timestream \
    --metric-name CumulativeBytesMetered \
    --dimensions Name=Operation,Value=WriteRecords Name=DatabaseName,Value=my_database \
    --start-time 2026-09-29T00:00:00Z --end-time 2026-10-13T00:00:00Z \
    --period 86400 --statistics Sum --region us-east-1

Interpretation: the LiveAnalytics CloudWatch page names this metric, and MagneticCumulativeBytesMetered for storage, and says the service keeps its statistics for two weeks, so sample a recent 14-day window, or read billed history from Cost Explorer. If a call returns no datapoints, run aws cloudwatch list-metrics --namespace AWS/Timestream to see the exact dimension combinations your account emits. Put write, storage, and query usage into the pricing calculator next to the InfluxDB instance or node size you plan to run.

How do measures and dimensions map to tags and fields?

LiveAnalytics stores records with a timestamp, dimensions (metadata such as region or host), a measure_name, and one or more measure values. InfluxDB stores points in line protocol: a measurement, a set of indexed tags, a set of unindexed fields, and a timestamp. AWS's transform script uses this default mapping:

# Single-measure record, as the transform README shows it
example_table,host=host1,region=us-west-2,request_id=saio3242ovnfk,measure_name=cpu_usage measure_value::double=0.66 1744933374702

# Multi-measure record
example_table,host=host1,region=us-west-2,request_id=saio3242ovnfk,measure_name=metrics cpu_usage=0.66,memory_usage=0.21 1744933374702

Interpretation: every distinct combination of tag values is a series. A dimension such as request_id is unique per event, so as a tag it creates one series per request. That is the main cause of memory pressure in InfluxDB 2. Move dimensions like that to fields. The example timestamp is 13 digits (milliseconds), while LiveAnalytics stores nanoseconds, so check the precision your queries need before a bulk load.

Measure cardinality before you choose

The InfluxDB target guide ships a cardinality script. It counts unique combinations of dimensions and measure name and suggests an instance type when the result is under 10 million.

python3 cardinality.py \
    --table-name example_table \
    --database-name example_database \
    --exclude-dimensions request_id,trace_id \
    --start-time '2026-10-01T00:00:00Z' --end-time '2026-10-05T00:00:00Z'

Interpretation: with --exclude-dimensions, the script also prints a "hypothetical cardinality" as if those dimensions became fields. If the number stays above 10 million even then, InfluxDB 2 is the wrong target and InfluxDB 3 Enterprise is the one to test.

What should existing LiveAnalytics customers do now?

Treat it as a planned move with no deadline. The order that avoids wasted work:

1. Inventory tables, retention, scheduled queries, and every consumer (dashboards, alerts, APIs).
2. Decide what history moves. The AWS evaluation guide asks whether you need full history or only the last 30, 60, or 90 days.
3. Test queries before data. AWS states that the InfluxDB 3 SQL dialect does not match LiveAnalytics one to one, so run your real query set on a development cluster.
4. Pick the target from the decision table, then follow the runbook.

Core is enough for query testing. For production, AWS's examples use InfluxDBv3Enterprise (3 nodes) or InfluxDBv3Enterprise1Node, and a custom parameter group for larger topologies.

# Confirm the endpoint and port before pointing a client at it
aws timestream-influxdb get-db-cluster --db-cluster-id a1b2c3d4e5 \
    --query '{endpoint: endpoint, port: port, status: status, engine: engineType}'

# Then list tables with the InfluxDB 3 CLI
influxdb3 query --host "https://<endpoint>:<port>" \
    --database "my-database" --token "$INFLUX_TOKEN" "SHOW TABLES"

Interpretation: engine should read INFLUXDB_V3_CORE. Take the port from the API rather than assuming one: the CLI reference says InfluxDB 3 defaults to 8181, while the cluster creation page's example connects on 8086. That page also shows --identifier, but the CLI reference names the option --db-cluster-id.

How do you migrate LiveAnalytics to Timestream for InfluxDB?

AWS's migration guide and the liveanalytics_migration_scripts folder of amazon-timestream-tools define a four-stage pipeline: unload to S3, transform to line protocol, ingest, and validate. The same S3 export also feeds the PostgreSQL path, so the first stage is never wasted.

Stage 1: export with UNLOAD

The export tool wraps the LiveAnalytics UNLOAD statement and splits the export into time chunks by hour, day (the default), month, or year. It can log progress to DynamoDB and send SNS alerts. AWS says each partition must stay under about 350 GB, or the query can fail with "The query computation exceeds maximum available memory".

python3 unload.py \
    --export-table \
    --database MyDB \
    --table MyTable \
    --start-time '2025-11-01 00:00:00' \
    --end-time '2026-10-05 00:00:00' \
    --partition day \
    --export-format PARQUET \
    --compression NONE \
    --s3-uri s3://my-migration-bucket \
    --enable-dynamodb-logger true

Interpretation: if you omit --end-time, the tool uses the current UTC time. After a failure, restart from the failed batch, not from the original start time. The AWS guide spells the logger flag --enable-dynamodb_logger and the tool's README --enable-dynamodb-logger, so confirm with --help. Under the hood, each chunk is a plain UNLOAD:

UNLOAD (
  SELECT * FROM "MyDB"."MyTable"
  WHERE time BETWEEN from_iso8601_timestamp('2026-10-01T00:00:00Z')
                 AND from_iso8601_timestamp('2026-10-02T00:00:00Z')
)
TO 's3://my-migration-bucket/MyDB/MyTable/2026-10-01/'
WITH ( format = 'PARQUET', compression = 'NONE' )

Interpretation: the UNLOAD reference sets the defaults to CSV and GZIP, so name both options explicitly. The bucket must be in the same account and Region, and UNLOAD also writes manifest and metadata files next to the data.

Stages 2 to 4: transform, ingest, and validate

The transform step loads the export into Athena and writes line protocol to S3 under <database>/<table>/unload-<timestamp>/line-protocol-output. The full pipeline runs from one config file.

python3 transform.py \
    --database-name example_database \
    --tables example_table \
    --s3-bucket-path example_s3_bucket \
    --dimensions-to-fields example_table=request_id \
    --add-validation-field false

# Whole pipeline (unload, transform, ingest, validate) for an InfluxDB 3 target
export INFLUXDB_V2_URL="https://<cluster-endpoint>:8181"
export INFLUXDB_V2_TOKEN="<operator-token>"
python main.py --config migration-config.yaml

Interpretation: the target README keeps the INFLUXDB_V2_* variable names for InfluxDB 3. You set influxdb_version to v3 in the config and leave out INFLUXDB_V2_ORG, because InfluxDB 3 has no organizations. The config also chooses batch mode (a fixed time range) or live_replication mode, which keeps both systems in sync while you cut over.

Overlapping batches are safe on InfluxDB 2. The InfluxDB v2 documentation treats points with the same measurement, tag set, and timestamp as one point and keeps the newest field values. Confirm the same behavior on InfluxDB 3 in your test cluster before you rely on overlap.

How do LiveAnalytics queries translate to InfluxDB 3 SQL?

Most query rewrites are mechanical, but none are automatic. LiveAnalytics uses bin(), ago(), and typed measure columns; InfluxDB 3 uses DataFusion SQL with date_bin() and now().

-- LiveAnalytics: 5-minute average CPU for the last hour
SELECT bin(time, 5m) AS t, avg(measure_value::double) AS avg_cpu
FROM "example_database"."example_table"
WHERE measure_name = 'cpu_usage' AND time > ago(1h)
GROUP BY 1 ORDER BY 1;

-- InfluxDB 3, after the default transform mapping
SELECT date_bin(INTERVAL '5 minutes', time) AS t,
       avg("measure_value::double") AS avg_cpu
FROM example_table
WHERE measure_name = 'cpu_usage' AND time > now() - INTERVAL '1 hour'
GROUP BY 1 ORDER BY 1;

Interpretation: the single-measure field keeps the name measure_value::double, which must be double-quoted in SQL. If your applications query many single-measure tables, rename fields during the transform or rewrite them as multi-measure records. Queries that rely on LiveAnalytics time series functions such as interpolation need a design review, not just a syntax change.

InfluxDB 2 is a bigger rewrite: queries move to Flux or InfluxQL, and scheduled queries become tasks.

What are the alternatives to Timestream for InfluxDB?

Timestream for InfluxDB is AWS's recommended successor, not the only option. The S3 export from stage 1 works for every target below.

• Aurora PostgreSQL or RDS for PostgreSQL. AWS documents this path for non-time-series use cases, loading the S3 export with AWS DMS (CSV and Parquet sources) or its copy_postgres.py tool. Use native partitioning for large tables.
• TimescaleDB. As of November 2026, TimescaleDB is not in the RDS for PostgreSQL or Aurora PostgreSQL extension lists. On AWS it runs self-managed, or on Tiger Cloud from Tiger Data (formerly Timescale).
• Self-managed InfluxDB. InfluxDB 2 OSS or InfluxDB 3 Core on EC2 or Kubernetes gives full control, but you own backups, upgrades, and failover.
• Amazon DynamoDB. AWS states that one InfluxDB 3 Enterprise cluster cannot currently take more than 1 million records per second. Above that, shard across clusters or, for low-complexity analytics, consider DynamoDB.
• Staying put. With a stable payer account and an acceptable bill, staying on LiveAnalytics is valid. Revisit it if AWS publishes an end-of-support date.

-- TimescaleDB 2.13+: one LiveAnalytics multi-measure table as a hypertable
CREATE TABLE example_table (
  time timestamptz NOT NULL, host text, region text,
  measure_name text NOT NULL, cpu_usage double precision
);
SELECT create_hypertable('example_table', by_range('time'));

Interpretation: dimensions become columns, as in AWS's PostgreSQL guidance. On Aurora or RDS, use declarative range partitioning on time instead of create_hypertable.

Which target should you choose?

This table condenses AWS's evaluation guidance and the limits above. Treat it as a starting point for a test.

Frequently asked questions

Key takeaways

Plan your Timestream migration with JusDB

JusDB's InfluxDB migration team can review your LiveAnalytics tables, retention, and query set, run the cardinality assessment with you, and help you choose between Timestream for InfluxDB 2, InfluxDB 3, and PostgreSQL-based targets. We can then plan and run the export, transform, and live replication cutover, with a rollback point agreed in advance.

Bring your table list, retention settings, a sample of dashboard and alert queries, and your current monthly usage. Your team approves every production change.

Related reading

• TimescaleDB hypertables, continuous aggregates, and compression
• TimescaleDB reliability engineering
• Time-series databases for AI and ML pipelines
• AWS documentation: Timestream for LiveAnalytics migration guide