A water monitoring programme generates a stream of timestamped readings from instruments at fixed locations. That sounds like a textbook time series database problem, and reaching for a specialist store is the obvious move.
It is usually premature. A few hundred sensors reporting every fifteen minutes is on the order of tens of millions of rows a year, and PostgreSQL handles that without complaint given an index and a little care.
Why plain PostgreSQL goes further than expected
The reason to start here is not performance, it is that water data is never only time series.
You have sites with coordinates, instruments with calibration histories, administrative boundaries, abstraction licences, laboratory results arriving on a different schedule, and quality flags applied by a human after the fact. All of that is relational, and PostGIS makes the spatial half native rather than bolted on.
Split the readings into a specialist store too early and every question that joins a reading to its site, its licence or its catchment becomes a join across two systems.
TimescaleDB, the incremental step
TimescaleDB is a PostgreSQL extension. Your readings table becomes a hypertable partitioned by time, you get compression and continuous aggregates, and everything else stays exactly where it was. Existing queries keep working and the spatial and relational data is still one join away.
For a water programme that has outgrown a plain table, this is almost always the right next move, precisely because it is not a migration.
InfluxDB, and when it is genuinely right
InfluxDB is built for time series and nothing else, and it is very good at that. High ingest rates, retention policies and downsampling as first class features, and a query language shaped around time.
It earns its place when ingest is genuinely high frequency, when the readings are largely self contained, and when the operational picture matters more than the analytical one. A SCADA style telemetry backbone for a large network is a fair example.
The cost is the split. Your contextual data still lives in a relational store, and you now maintain two.
How to choose
- Under roughly ten million readings a year, lots of context. PostgreSQL with PostGIS. Do not over engineer.
- Growing, queries getting slow, context still central. TimescaleDB. It is an extension, not a rewrite.
- Very high frequency, operational, little context. InfluxDB.
- Raster and satellite archives. None of the above. That is object storage with a spatial index over it.
What actually determines the answer
Monitoring systems rarely fail on storage. They fail on ingest and on quality control: a logger that stops reporting and nobody notices for six weeks, a clock drift nobody corrects, a unit change between firmware versions, a gap that silently becomes a zero in the dashboard.
Budget for the boring half. Gap detection, automated flagging, calibration tracking and an alert when a station goes quiet will do more for the value of the record than any database choice.
We build this layer on municipal network and industrial site work, where the monitoring exists to keep a model and a decision anchored to what is actually happening. Our software and AI services cover the pipeline, and where it feeds something a team acts on each day it is a decision support system.