The service named Timestream now means two different products, and only one of them accepts new customers. This is the definition, the decision, a working InfluxDB 3 write-and-query loop, and the export path out of LiveAnalytics. Plan for 90 minutes, mostly waiting for a cluster to provision.
What it actually is
Amazon Timestream is AWS's managed time-series database family, and the family just split. Timestream for LiveAnalytics, the original serverless engine with a memory store and a magnetic store, is closed to new customers as of June 20, 2025. AWS's own page says existing workloads are unaffected and accounts with an active payer can keep adding users and linked accounts, but anyone starting fresh is pointed at Timestream for InfluxDB. The availability change notice gives no end-of-support date. It says AWS "continues to invest" in security and availability, which is a promise to keep the lights on, not a promise of new features.
So the honest definition in late 2026 is this: Timestream is a managed InfluxDB. You choose a version (2 or 3), AWS operates the servers, patching, backups and failover, and you talk to it with open InfluxDB APIs and line protocol. This article is the EOL-guard version of the encyclopedia entry: what you would be inheriting if you already run LiveAnalytics, what replaced it, and a build against the successor. It does not teach you to start a new LiveAnalytics database, because you cannot.
The model
Timestream for InfluxDB 3 is the interesting half, because InfluxDB 3 is a rewrite. Versions 1 and 2 used the TSM storage engine. Version 3 uses Apache Arrow in memory, Apache DataFusion for query execution, and Parquet files in Amazon S3 for persistence, per the InfluxDB 3 service docs. Compute and storage are decoupled. Nodes keep local caches, the data lives in S3.
The unit you create is a DB cluster, in one of two editions. Core is single-node only and has no compaction, so AWS positions it for near real-time workloads over recent data, a few days old. Enterprise supports multi-node clusters and compaction, and it carries an extra InfluxData license billed per vCPU-hour through AWS Marketplace. Without compaction, small Parquet files pile up and queries slow down, which is the whole reason Core is not a long-retention product.
The data model is the one InfluxDB users know. A database holds tables (measurements), rows have a timestamp, tags (indexed dimensions) and fields (values). You write line protocol, you query with SQL (the primary language, via DataFusion) or InfluxQL for backward compatibility. Auth is token-based: an operator token (the first admin token) with full access, and resource tokens scoped to databases. For the cluster itself, the docs say the operator token is stored in AWS Secrets Manager under a secret named after the cluster identifier.
What AWS operates: provisioning, patching, backups, the DNS endpoint, multi-AZ placement for Enterprise nodes. What you operate: schema discipline (tags versus fields), batching, tokens, security groups, and retention.
When to use it, when not to
The comparison people actually need is Timestream against a plain relational database with a time column, against CloudWatch for infrastructure metrics, and against the old LiveAnalytics.
Need | Timestream for InfluxDB 3 | Postgres (RDS/Aurora) | CloudWatch |
|---|---|---|---|
High-cardinality metrics with SQL | Built for it | Works to a point, then partitioning pain | Metric-count and dimension limits |
Existing Telegraf/InfluxDB tooling | Native | Needs adapters | Agent only |
Joins with business data | Possible in SQL, not its strength | Native | No |
Zero servers to size | No, you pick a node class | No | Yes |
Long retention, cheap | Object storage, Enterprise compaction | Expensive at scale | Tiered, fixed |
Use it when your workload is IoT, telemetry or application metrics, you want open APIs so you can leave, and you can live with sizing a cluster. Skip it when you are storing a few thousand rows a day (Postgres is simpler), when you only need AWS infrastructure metrics (CloudWatch already has them), or when the workload is relational with a timestamp bolted on.
If you already run LiveAnalytics: nothing forces you to move today, but there is no roadmap promise either. The migration guide lists three targets: InfluxDB 3 (recommended for most workloads), InfluxDB 2 (for low-latency operational workloads), and Aurora or RDS PostgreSQL for non-time-series use cases. Amazon S3 is the intermediate layer in every path.
What it costs
InfluxDB 3 bills on four lines, per the service docs. Node hours, billed per second with a 10-minute minimum, per node. Object storage per GB-month on actual data stored, with a minimum monthly charge equivalent to 200 GB. Data transfer out to the internet or other regions (transfer in and within a VPC or between AZs in a region is free). And for Enterprise only, the per-vCPU-hour license through Marketplace. I/O against S3 is bundled into the node price for the I/O-included classes, so you do not get a surprise request bill.
The surprise is the 200 GB storage floor. A tutorial cluster holding 4 MB still pays for 200 GB for the month, prorated by however long it exists, so a one-hour test is cheap but a forgotten cluster is not. Second surprise: the docs list the node classes as db.influxIOIncluded.* (medium 1 vCPU/8 GiB up to 24xlarge 96 vCPU/768 GiB), while the create-cluster example uses --db-instance-type db.influx.large. Check which string your CLI version and Region accept before you script it.
I could not retrieve a per-hour rate for the InfluxDB 3 classes from the pricing page when I wrote this, and I will not quote one from memory. The pricing page is where to read it. The estimate formula for following along is: (node hourly rate x about 2 hours of runtime) plus (200 GB x the object storage rate x the fraction of a month the cluster exists). For a single-node Core cluster deleted the same day, expect cents to low single-digit dollars, but confirm with the rates for your Region. For reference, the same page lists the older InfluxDB 2 instances at $0.956 per hour for db.influx.2xlarge single-AZ, and multi-AZ doubles both instance and storage rates.
Free tier: do not count on one for InfluxDB. Treat everything here as billable.
The limits that bite
The docs publish sizing guidance rather than hard quotas. For a test workload of Telegraf agents writing 5,000-line requests against 30 million series, AWS suggests Core on large for about 150,000 lines per second with under 25 queries per second, Enterprise 4xlarge for about 500,000 lines per second at about 50 queries per second, and multi-node Enterprise beyond 750,000 lines per second. Those are the vendor's numbers on one workload, not guarantees.
The limits that actually bite are architectural. Core has no compaction, so query latency degrades as files accumulate. A cold Parquet cache after a restart makes the first queries slow. The query-file-limit parameter caps how many Parquet files one query scans. And write batches matter: the docs recommend 5,000 to 10,000 lines or 10 MB per request, gzip for big payloads, and the coarsest timestamp precision that fits.
For migration, LiveAnalytics exports cap out in a different way: each export partition should stay under roughly 350 GB or you will hit "query computation exceeds maximum available memory".
Build it
We will create a single-node InfluxDB 3 Core cluster, write sensor readings with line protocol, and query them with SQL. This assumes a default VPC and that you run the commands from an EC2 instance or bastion inside it, because the cluster in this example is private.
Prerequisites: AWS CLI v2 recent enough to include timestream-influxdb cluster commands, Python 3.10+, an EC2 instance in the same VPC with the cluster's security group allowing port 8086 (the default port), and an IAM principal that can call the service. The docs do not publish a minimal policy for this flow, so start from a policy granting the timestream-influxdb:* actions on a scratch account, plus secretsmanager:GetSecretValue for the operator token and the EC2/VPC read permissions the console needs. Tighten it after it works. For private clusters, the docs also require the S3 policies described on their S3 VPC endpoint page.
Step 1: create the cluster. The documented command for Core, single node:
aws timestream-influxdb create-db-cluster \
--region us-east-1 \
--name "sl-timestream-demo" \
--db-parameter-group-identifier "InfluxDBv3Core" \
--db-instance-type db.influx.large \
--vpc-subnet-ids subnet-REPLACE1 subnet-REPLACE2 \
--vpc-security-group-ids sg-REPLACE \
--publicly-accessible false
The edition comes from the parameter group, not an engine flag: InfluxDBv3Core for Core, InfluxDBv3Enterprise for a 3-node Enterprise cluster, InfluxDBv3Enterprise1Node for a single Enterprise node. Provisioning takes roughly 10 to 20 minutes.
Step 2: get the endpoint and token. Poll until the status is Available, then read the cluster:
aws timestream-influxdb get-db-cluster --identifier "CLUSTER_ID_FROM_STEP_1"
aws secretsmanager get-secret-value --secret-id "CLUSTER_ID_FROM_STEP_1" \
--query SecretString --output text
The first command returns the endpoint (a hostname ending in timestream-influxdb3.<region>.on.aws). The second returns the operator token, because the docs say the secret is named after the cluster identifier. Export both so the next steps read them from the environment, never from source:
export TS_HOST="your-endpoint-hostname:8086"
export TS_TOKEN="paste-operator-token"
Step 3: write data. The native endpoint is POST /api/v3/write_lp. This Python script writes two minutes of fake sensor readings in one batch. It uses only the standard library plus requests, and it sets precision=s explicitly:
import os, time, requests
host, token = os.environ["TS_HOST"], os.environ["TS_TOKEN"]
now = int(time.time())
lines = []
for i in range(120):
ts = now - (120 - i)
for room, base in (("kitchen", 21.0), ("lab", 24.5)):
lines.append(f"home,room={room} temp={base + (i % 7) * 0.1:.1f},hum={35 + i % 5}i {ts}")
r = requests.post(
f"https://{host}/api/v3/write_lp",
params={"db": "sensors", "precision": "second"},
headers={"Authorization": f"Bearer {token}"},
data="\n".join(lines),
timeout=30,
)
print(r.status_code, r.text[:200])
One caution: the docs show precision values as ns, us, ms, s in the write page. If your cluster rejects second, use s. Also, the TLS certificate on a private cluster may need your CA bundle; if requests complains, fix the trust store rather than disabling verification.
Step 4: query with SQL. The HTTP endpoint is /api/v3/query_sql:
import os, requests
host, token = os.environ["TS_HOST"], os.environ["TS_TOKEN"]
q = """
SELECT date_bin(INTERVAL '30 seconds', time) AS bucket, room,
avg(temp) AS avg_temp, count(*) AS n
FROM home
WHERE time >= now() - INTERVAL '10 minutes'
GROUP BY bucket, room
ORDER BY bucket, room
"""
r = requests.get(
f"https://{host}/api/v3/query_sql",
params={"db": "sensors", "q": q, "format": "csv"},
headers={"Authorization": f"Bearer {token}"},
timeout=30,
)
print(r.status_code)
print(r.text)
date_bin is the DataFusion time-bucketing function the docs list for SQL, where InfluxQL would use GROUP BY time(). SQL also gives you joins, subqueries and native parameterized queries; InfluxQL does not.
Verify it works
The write call should return a success status (the write docs do not state the exact code, so treat any 2xx with an empty body as success). The query returns CSV with a header bucket,room,avg_temp,n and one row per 30-second bucket per room, roughly eight to ten rows for two minutes of data. Add up the n column: it should equal 240, which is 120 seconds times 2 rooms. Partial buckets at the edges hold fewer points, and that is expected.
A second check is cheap and worth doing: rerun the write script a minute later and rerun the query. The timestamps are computed from the current time, so the new rows land at new timestamps and the total grows. Rows that share the same tags and timestamp are treated as the same point, so replaying an identical batch will not double the count. Test that behavior yourself before you rely on it for deduplication.
Getting data out of LiveAnalytics
If you are migrating rather than starting, the documented path has two stages. First export to S3 with the LiveAnalytics export tool, which uses UNLOAD under the hood:
python unload.py \
--export-table \
--database MyDB \
--table MyTable \
--start-time '2024-05-14 00:00:00' \
--end-time '2025-05-14 00:00:00' \
--partition month \
--export-format PARQUET \
--region us-east-1 \
--s3-uri s3://my-bucket
The tool lives in the awslabs/amazon-timestream-tools repository under the LiveAnalytics migration scripts. For a Timestream for InfluxDB target, the docs say to use Parquet without compression for compatibility with the ingestion scripts, so drop --compression GZIP from the advanced example. Keep partitions under about 350 GB, restart from the failed batch rather than from the beginning, and use the same migration tag if you want files under the same prefix. The second stage ingests from S3 into the InfluxDB target using the scripts described on the migration guide's target page, which I did not retrieve in full, so read it before you plan a cutover.
When it breaks
HTTP 401 on any call means the token is missing, expired or lacks permission. For resource tokens, confirm read access on that database. Regenerate if it may have been revoked.
A connection timeout from your laptop is expected on a private cluster. The Explorer UI and any client must run inside the same VPC, such as an EC2 instance or bastion, with port 8086 open in the security group.
The create call rejecting your instance type is the naming mismatch above. List what the docs and your CLI accept, and try the db.influx.* form from the create example before db.influxIOIncluded.*.
Queries that start fast and slow down over days on Core are the missing compaction. Either keep Core to short-retention data or move to Enterprise.
Writes returning 400 with partial acceptance come from accept_partial, which defaults to true: valid lines land, invalid ones are rejected. Check the response body, not just that something was written. And no_sync=true acknowledges before the write-ahead log, so a crash can lose data you were told succeeded.
Cleanup
Delete the cluster, then confirm nothing is left to bill:
aws timestream-influxdb delete-db-cluster --identifier "CLUSTER_ID_FROM_STEP_1"
aws timestream-influxdb list-db-clusters
Delete the EC2 instance if you created one, and delete the Secrets Manager secret if it survives the cluster. Remember the 200 GB storage minimum is charged for the time the cluster existed, so the clock stops only at deletion. Check Cost Explorer the next day for lines tagged Timestream.
Where to take it next
Easiest: point Telegraf at the cluster, which is the path the getting-started guide takes, and watch real host metrics arrive. Next: add a resource token scoped to write-only on one database and give that to your producers, keeping the operator token out of applications. Hardest: take a real LiveAnalytics table, export a month to Parquet, ingest it, and compare query results between the two engines before you commit to a cutover date.
The thing worth sitting with is that a "managed service" can still be a product you cannot start. Pick the infrastructure whose interfaces you can leave.
