Sooner or later every IoT project has to answer where the readings will live. Two answers dominate: a time-series database built for timestamped measurements, or a data lake of files in object storage queried with analytics engines. Teams often frame this as either-or. The better framing is: which questions will people ask, how fast do they need answers, and how long must the data last?

Start From the Questions

Storage decisions go wrong when they start from technology. Write down the questions first and sort them into two buckets.

Operational questions are about now and the recent past. What is the current temperature on this machine? Did any device cross a limit in the last hour? Show me the last day for this site. These need quick responses, often to a dashboard or an alert rule, over a narrow slice of recent data.

Analytical questions are about patterns across lots of data. How does vibration behave before a failure across the whole fleet over a year? Which device models drift most? These scan large volumes, tolerate seconds or minutes of response time, and often join sensor data with other sources such as maintenance logs.

A time-series database is shaped for the first bucket. A data lake is shaped for the second. Most mature IoT systems end up with both.

What a Time-Series Database Does Well

These systems are built around the fact that sensor data arrives in time order, is mostly appended and rarely updated, and is nearly always queried by time range and device. Typical strengths include efficient writes at high rates, compression suited to timestamped values, built-in functions for downsampling and rolling windows, and retention rules that expire old data automatically.

The trade-offs: they can become expensive or slow when you keep very long histories at full resolution, and they are less comfortable for wide, ad-hoc analysis that combines many datasets. Features vary considerably between products, so check current documentation for limits on cardinality, meaning how many distinct series you can track.

What a Data Lake Does Well

A data lake stores raw or lightly processed data as files, commonly in columnar formats, in inexpensive object storage. Compute is separate from storage, so you pay for queries when you run them. This is excellent for long retention, reprocessing history when your logic changes, and machine learning work that needs large training sets.

The trade-offs: latency is usually unsuited to live dashboards, small frequent writes produce many tiny files unless you batch, and you need discipline around partitioning, schema and file layout. Without that discipline a lake slides into an expensive swamp where nobody trusts the contents.

Comparing the Two

Aspect	Time-series database	Data lake
Best for	Recent data, dashboards, alerts	Long history, fleet-wide analysis
Query speed on narrow time ranges	Typically fast	Typically slower
Long retention at full resolution	Can get costly	Generally economical
Reprocessing history	Awkward	Natural
Operational effort	Database to run or subscribe to	Layout, partitioning, catalog discipline
Ad-hoc joins with other data	Limited	Strong

The Hybrid Most Teams Land On

A frequent pattern is to write incoming data to both. The time-series store holds recent data, say weeks or months, at full resolution for operational use. The lake receives everything, in batches, as the permanent record. Over time, the time-series store keeps downsampled aggregates for older periods, and detailed history lives in the lake.

This gives fast dashboards, cheap history and the freedom to rebuild derived datasets when you find a bug in your processing. It also makes the lake your source of truth, which simplifies recovery: you can repopulate the operational store from it.

The cost is complexity. Two systems mean two sets of permissions, two places for schema changes, and a pipeline in between. Do not adopt the hybrid because it sounds mature. Adopt it when a single store clearly cannot meet both needs.

A Hypothetical Example

Consider a company monitoring industrial pumps. Technicians use a dashboard showing the last few days of pressure and flow, and an alert fires when readings leave a safe band. Separately, an engineer wants to study how pump behavior changes in the weeks before bearing failures across all sites.

The dashboard and alerts run on a time-series store with a short retention window. A nightly job writes the day’s raw readings into object storage partitioned by date and site. The engineer queries the lake for months of history. When the team later changes how it computes a derived metric, they rerun the calculation over the lake rather than trying to patch years of stored results.

Pitfalls

One is storing everything at maximum frequency forever in the operational database because deletion feels risky. Define retention tiers on day one: full resolution for a short window, aggregates for longer, raw archive in the lake.

Another is skipping a stable schema and device identifier. If the same sensor appears under three naming schemes, no storage choice will rescue your analysis.

A third is making the lake too fine-grained. Writing every message as its own tiny file makes queries painfully slow. Batch writes into larger files on a schedule.

Frequently Asked Questions

Can I just use a general-purpose relational database? For small fleets and modest data volume, yes, and it can be a sensible start. Plan for the point where write rates and retention make a specialised store worthwhile.

What does “cardinality” mean here? It is the number of distinct series, typically device and metric combinations. Some time-series databases slow down or cost more as this grows, so check how your choice behaves.

Do I need a lake if I am not doing machine learning? Not necessarily. If operational queries and short retention satisfy your needs, a time-series store alone may be enough. A lake pays off with long history and reprocessing needs.

How long should I keep raw data? As long as it has a use, a contractual requirement or a regulatory obligation. Requirements vary, so confirm with the people who own compliance.

Is it hard to add the lake later? Not if you keep raw messages somewhere durable from the start. Adding a lake is easy when the data still exists and painful when it does not.

Next Step

List the ten questions your team asks of the data most often, mark each as operational or analytical, and note the time range involved. If almost all are operational, start with a single time-series store. If a meaningful share are analytical, plan the lake from the beginning.