DEV Community

Cover image for Amazon Timestream: The Database Built for Time-Series Data
Tanseer for AWS Community Builders

Posted on

Amazon Timestream: The Database Built for Time-Series Data

A serverless database made for data that arrives with a timestamp, like sensor readings, metrics, and events. Stop six in the AWS Hidden Gems series.

About this series

Most AWS learning stops after EC2, S3, IAM, and Lambda. But AWS has over two hundred services, and many of the most useful ones rarely appear in tutorials.

AWS Hidden Gems covers those underrated services you shouldn't ignore. Each article picks one, then explains why it exists, what it does, where it fits, and how to set it up from the console. Know the four basics above and you can follow along. Everything else gets explained as it comes up.

Today's service: Amazon Timestream

Some data is defined by when it happened: a temperature reading every second, a server's CPU usage over a day, a stock price tick by tick. This is time series data, and normal databases handle it poorly at scale. Timestream is a database built specifically for it.

Why does this service exist?

Time series data has an awkward shape. It arrives constantly and in huge volumes, you almost always query it by time ranges, and older data becomes less useful but you still want to keep it cheaply. General purpose databases struggle here. A relational database gets expensive and slow under a firehose of writes, and you end up over provisioning servers and hand building ways to expire old data.

Timestream is designed around this shape. It is serverless, so it scales writes automatically with no servers to size. It stores recent data in a fast tier and moves older data to a cheaper tier on its own. And its query language has time series functions built in, for things like filling gaps between readings.

What is Amazon Timestream?

Timestream is a serverless time series database. Time series data is a sequence of values recorded over time, each stamped with the moment it happened.

A record in Timestream has three parts:

  • Dimensions: labels that describe the source, like a device id or a region
  • Measures: the actual values, like temperature or CPU percentage
  • Time: when the measurement was taken It stores data in two tiers automatically. A memory tier holds recent data for fast queries, and a magnetic tier holds older data at lower cost. You set how long data stays in each with a retention policy, and Timestream moves data between them for you. You query it with SQL, the standard database query language, extended with functions made for time.

A real world problem

A company runs a few hundred temperature sensors across its warehouses, each reporting every ten seconds. That is millions of readings a day, forever.

They tried storing this in their existing relational database. Writes started to lag, storage costs climbed, and queries like average temperature per warehouse over the last hour got slow. The database was not built for this kind of load.

Moving the readings to Timestream fixes it. Writes keep up automatically, recent data stays fast to query, old data ages into cheap storage, and the time based queries they need are quick. Their database goes back to handling the business data it is good at.

Real world use cases

  • IoT platforms store sensor readings from thousands of devices reporting constantly
  • Operations teams keep server and application metrics for monitoring and alerting
  • Industrial systems track machine data to spot problems before a breakdown
  • Energy and utilities record meter readings over time for analysis and billing
  • Finance stores market data like prices and trades stamped to the moment
  • Apps log user activity events for later analysis by time The pattern is a high volume stream of timestamped values that you query by time.

Where it fits in AWS

Data usually flows in from many small producers. Devices send readings through IoT Core, or an app or stream writes records directly. Timestream stores them, and you query from a dashboard tool like Amazon Managed Grafana or Amazon QuickSight to see trends.

flowchart LR
    A[Sensors and devices] --> B[IoT Core]
    B -->|Route readings| C[Timestream]
    D[Apps and streams] -->|Write records| C
    C -->|SQL queries| E[Grafana or QuickSight dashboards]
Enter fullscreen mode Exit fullscreen mode

Timestream is the store for the time series itself. Other services feed it and visualize it, and it focuses on ingesting and querying by time.

How the workflow runs

You create a database and a table, and set the table's retention: how long data stays in the fast memory tier and how long in the cheaper magnetic tier. Producers write records, each carrying dimensions, one or more measures, and a timestamp. Timestream keeps recent records in memory for fast access and ages older ones into magnetic storage on schedule. You run SQL queries over any time range, and Timestream reads from whichever tier holds that data.

flowchart TD
    A[Create database and table] --> B[Set memory and magnetic retention]
    B --> C[Producers write timestamped records]
    C --> D[Recent data in fast memory tier]
    C --> E[Older data in cheap magnetic tier]
    D --> F[SQL queries by time range]
    E --> F
Enter fullscreen mode Exit fullscreen mode

Setting it up in the AWS Console

You will create a database and table, write a couple of records, and query them. This uses Timestream for LiveAnalytics, the serverless engine.

  1. Sign in to the AWS Console, search for Timestream, and open it. Check the region in the top right corner.
  2. In the left menu choose Databases, click Create database, select Standard database, give it a name, and create it.
  3. Open your database, choose Tables, and click Create table. Name the table, then set the retention, for example keep 12 hours in the memory tier and 7 days in the magnetic tier. These control how long data stays fast versus cheap.
  4. To add data quickly, open the Query editor from the left menu. Timestream expects most writes to come from code, but you can confirm the table exists and is queryable here.
  5. Write a few records using the code in the next section, sending a device id as a dimension, a temperature as a measure, and the current time. This is the normal way data enters Timestream.
  6. Back in the Query editor, run a query such as selecting all rows from your table ordered by time, and confirm your records appear. Timestream gives you sample queries you can adapt.
  7. To validate a real time based query, try averaging your measure grouped by device over the last hour, and check the numbers match what you wrote. Common mistakes: a write that is rejected often has a timestamp outside the memory tier's retention window, so make sure you are writing recent times. An access error means the IAM role is missing Timestream write or query permission, so add it.

Using it from code

Timestream splits writing and querying into two clients. This writes a single temperature reading.

import boto3
import time

write_client = boto3.client("timestream-write")

now = str(int(time.time() * 1000))  # current time in milliseconds

write_client.write_records(
    DatabaseName="my-database",
    TableName="sensors",
    Records=[
        {
            "Dimensions": [{"Name": "device_id", "Value": "sensor-1"}],
            "MeasureName": "temperature",
            "MeasureValue": "22.5",
            "MeasureValueType": "DOUBLE",
            "Time": now,
        }
    ],
)

print("Wrote one reading")
Enter fullscreen mode Exit fullscreen mode

To read the data back, use the timestream-query client and run a SQL statement like SELECT device_id, temperature, time FROM "my-database"."sensors" ORDER BY time DESC.

Pricing

Item Detail
Writes Per GB of data written
Memory tier storage Per GB per hour, for recent fast data
Magnetic tier storage Per GB per month, cheaper, for older data
Queries Per GB of data scanned by the query
Free tier Monthly write, storage, and query allowance for new accounts

The AWS database family

AWS Databases
├── Timestream    time series data like sensors and metrics
├── DynamoDB      key value and document data at any scale
├── Aurora/RDS    relational SQL databases
├── ElastiCache   in memory caching for speed
└── Neptune       graph data and relationships
Enter fullscreen mode Exit fullscreen mode

AWS offers a database per job rather than one for everything. Timestream is the one for timestamped streams. DynamoDB is the general NoSQL workhorse, and Aurora or RDS handle relational data. Pick Timestream when time is the main axis of your data.

Wrapping up

Timestream is built for the exact shape of time series data: constant writes, time based queries, and old data you want to keep cheaply. It scales itself, tiers your data by age, and speaks SQL. Next time you are about to force sensor or metric data into a general database, reach for this instead.

Series progress

You are on stop six of AWS Hidden Gems.

  1. AWS Elemental MediaConvert
  2. Amazon IVS
  3. Amazon Rekognition
  4. Amazon Personalize
  5. AWS AppSync
  6. Amazon Timestream (you are here)
  7. Amazon Textract
  8. Amazon Kendra
  9. AWS DataSync
  10. AWS IoT Core Next up is Amazon Textract, which pulls text, forms, and tables out of scanned documents using AI.

Let's connect

Questions, corrections, or want to talk through where this fits in your own project? Reach me at khantanseer43@gmail.com.

Top comments (0)