Storage math first: 50,000 sensors × 1/minute × 60 minutes × 24 hours × 90 days = 6.48 billion points. At roughly 50 bytes per point uncompressed, that is 324GB raw. With 5x compression (typical for time-series), you are at roughly 65GB on disk. That fits easily on a single node for both InfluxDB and TimescaleDB.

For the technology choice: if your team knows PostgreSQL and needs features like full-text search, JSON support, or complex joins across sensor metadata, TimescaleDB is a natural fit. If you need maximum write throughput and are comfortable with InfluxQL or Flux, InfluxDB handles this write volume easily. The deciding factor is usually team expertise and whether you need PostgreSQL compatibility. At 50,000 sensors and 1 reading per minute, you are well within single-node capacity for either.

The most likely cause is that you are querying raw data across too wide a range. If you have 1-minute resolution data kept for 90 days and you query 30 days at a time, you are scanning 43,200 minutes of data per series. If you have thousands of series in a single query, that is tens of millions of points to decompress and aggregate.

The fix is downsampling. Create a continuous query that rolls up your 1-minute data into 1-hour or 1-day aggregates. Query the downsampled data for long ranges and only hit raw data for recent windows. Alternatively, if you cannot downsample, check whether your tag set is causing high cardinality — too many unique tag values force InfluxDB to scan more series than necessary even within a time range.

InfluxDB's TSM engine organizes data by time into TSM files, each covering a shard group time range. Within each TSM file, data is sorted by measurement, tag set, and field, then compressed. Queries read only the TSM files that overlap with the requested time range. TimescaleDB's chunking is similar but built on PostgreSQL table partitioning — each chunk is a separate PostgreSQL table, and the TimescaleDB hypertable is a view over all chunks. Queries against a time range hit only the relevant chunks, and the PostgreSQL query planner handles it.

The operational difference: TimescaleDB chunks are PostgreSQL tables, so you can query them with standard SQL, join them to other PostgreSQL tables, and use PostgreSQL tooling. InfluxDB TSM files are proprietary and opaque — you cannot query them directly and must use InfluxQL or Flux.

Store all timestamps in UTC internally. This eliminates a whole class of bugs where local time zones cause aggregation misalignment. Most time-series databases store timestamps in UTC by default. At query time, use the timezone parameter in your query language to convert to the display timezone. In InfluxQL: GROUP BY time(1h, TZ('America/New_York')). In TimescaleDB: time_bucket('1 hour', time AT TIME ZONE 'UTC' AT TIME ZONE 'America/New_York'). Never store local time zones in the database — it creates edge cases around daylight saving transitions that are painful to debug.

The core tension is between tenant isolation and cross-tenant analytics. Two main approaches:

Separate databases per tenant: Cleanest isolation, natural backup and restore boundaries, but cross-tenant queries require external aggregation. Good for high-security tenants or when tenant count is bounded (dozens, not thousands).

Shared database with tenant tag: Store tenant_id as a tag in InfluxDB or a partition key in TimescaleDB. Query performance relies on tag/cardinality management. With TimescaleDB, use tenant_id as a partition dimension alongside time. Cross-tenant aggregates become range scans on the tenant_id tag — acceptable if tenant count is manageable and you have downsampled data for long-range analytics.

For InfluxDB specifically, keep tenant_id as a low-cardinality tag (bounded set of tenants, not unbounded device IDs). If you have 500 tenants each with 10,000 devices, the tag cardinality is 500 — manageable. If you try to make device_id a tag, you have millions of series and query performance collapses.

InfluxDB continuous queries run on a schedule (every hour, every 5 minutes) and execute a SELECT INTO query against the database. They run inside the InfluxDB process, so there is no network overhead. They are triggered by time, not by data arrival.

TimescaleDB continuous aggregates are implemented as materialized views that automatically refresh based on a policy. TimescaleDB tracks the last refresh time and only recomputes rows in the interval since the last refresh — more efficient than a full recompute.

Why write-time downsampling beats read-time: When you query raw data and aggregate at read time, you pay the decompression and scan cost on every query. If 100 users query 30-day ranges, you decompress the same data 100 times. With write-time downsampling, you compute once (when data arrives) and store compact summaries. Every subsequent query is fast because it reads pre-aggregated data.

The tradeoff: write-time downsampling means you decide the aggregation granularity upfront. If you later need 15-minute resolution but only downsampled to 1-hour, you cannot recover the 15-minute data. Read-time aggregation preserves full flexibility but costs more at query time.

Days 0-1 (raw ingestion): 1 reading per 5 seconds = 720 readings per hour = 17,280 per day. At 50 bytes per point, raw storage grows about 864KB per day per sensor. For 10,000 sensors, that is roughly 8.6GB per day.

Day 1 onward (TSM compaction): InfluxDB flushes the cache to TSM files. Background compaction merges small TSM files into larger ones, applying compression. TSM compression on temperature data (repetitive timestamps, similar values) typically achieves 5-10x. That 8.6GB might compress to 1-2GB on disk.

Day 90 (retention boundary): The 90-day retention policy kicks in. At the exact 90-day mark, InfluxDB drops the oldest TSM files. The data is gone — not archived, not moved. Make sure your downsampled data has already been written to the hourly measurement before this happens.

Post-90 days (downsampled only): You have 1 reading per hour instead of 720. That is 24 points per day instead of 17,280 — a 720x reduction. Storage for 90 days of hourly data is roughly 864KB * 24 / 720 = ~29KB per sensor per 90 days. A massive saving.

High cardinality means a tag or index has many unique values. In InfluxDB, each unique measurement + tag set combination is a series. If you have 1 million device IDs as a tag and each device sends 10 fields, you have 10 million series. InfluxDB must maintain an in-memory series index — too many series exhaust RAM and slow down queries.

Common causes of high cardinality: Using user IDs, session IDs, email addresses, or transaction IDs as tags. These have millions of unique values. Storing GPS coordinates as separate lat/lon tags with high precision. Using UUIDs as tag values.

Design patterns to avoid it: Encode coarse-grained dimensions instead of fine-grained ones. Instead of device_id as a tag, use device_type or region. Instead of exact lat/lon, use geohash cells. Instead of user_id, use user_segment or account_tier. The goal is tags with thousands of unique values, not millions.

If you genuinely need per-device queries, consider TimescaleDB where device_id becomes a column with a B-tree index — different tradeoffs than InfluxDB's inverted index model.

InfluxDB write path: WAL write + in-memory cache index → acknowledgment. No fsync to TSM files on every write. Achieves 100k-500k points per second per node. If you need maximum write throughput and are comfortable with InfluxQL, InfluxDB is fastest for pure time-series inserts.

TimescaleDB write path: PostgreSQL write + WAL + B-tree index updates on every insert. Indexes on tags cause overhead — each write must update the tag index. Throughput is lower than InfluxDB but still high (tens of thousands of points per second). Better if you need SQL compatibility and have complex metadata relationships.

ClickHouse write path: Append-only columnar storage. Writes go to a partition buffer, then get merged into sorted parts. Very high throughput for analytical workloads (100k+ pts/s). Best for analytical queries on time-series data with complex aggregations. Higher operational complexity due to cluster setup.

Decision framework: Choose InfluxDB for pure metrics collection with simple tag filtering. Choose TimescaleDB when you have PostgreSQL expertise and need to join time-series data with relational metadata. Choose ClickHouse when your workload is analytical-heavy and you have the operational maturity to manage a distributed columnar database.

Write-side signals: Monitor ingest rate (points/second) and watch for sustained drops below your baseline. Write latency p99 creeping upward. WAL file size growing — if the WAL is not flushing to TSM files fast enough, it means compaction is falling behind. A growing WAL eventually exhausts disk space.

Query-side signals: Query latency p99 is the most important signal. A rising p99 means the system is struggling to decompress data or is scanning too many chunks. If query latency is stable but user-facing dashboards are slow, check whether they are querying raw data for long ranges when downsampled data exists.

Storage signals: Disk usage growth rate. If disk growth outpaces your retention policy deletion rate, the compaction backlog is growing. Compression ratio dropping (diskn/diskd metrics in InfluxDB) suggests the TSM files are not compacting properly.

TimescaleDB-specific: Monitor chunk count — too many chunks (thousands) means partition overhead is dominating. Check timescaledb_information.jobs for continuous aggregate refresh lag. If the background job has fallen behind, your downsampled data is stale.

Migration strategy: Use the InfluxDB export functionality (influx inspect export) to export cold data as line protocol. Export in time-order chunks — oldest first. This gives you manageable file sizes (do not try to export 2 years in one shot).

Parallel ingestion: TimescaleDB can use COPY or \COPY for bulk loading. Pre-create the hypertable with the correct chunk interval before importing. For 2 years of data with 90-day chunks, you need roughly 8-9 chunks. Use timescaledb.parallel_copy extension if available for faster ingestion.

Downtime window: The cleanest approach is dual-write during migration — write to both InfluxDB and TimescaleDB for the migration period. Then do a final sync of any data written during migration, switch the application to TimescaleDB, and decommission InfluxDB.

Validation: Compare row counts between systems for each time range. Spot-check aggregations (sum, mean, min, max) on sample measurements to confirm values match within tolerance. Check that timestamps are preserved exactly.

InfluxDB: Out-of-order writes go through the normal write path but may land in a different TSM file than expected (based on timestamp). InfluxDB has a out_of_order write option in recent versions that allows batching out-of-order points. The impact is that data with timestamps far in the past does not compress as well because similar timestamps are not grouped together.

TimescaleDB: PostgreSQL handles out-of-order inserts as normal inserts. The chunk containing that timestamp receives the data. If timestamps are truly historical, they land in older chunks that may already be compressed. This can cause index bloat and worse compression ratios.

Storage efficiency implication: Out-of-order data harms compression because time-series compression relies on similarity between adjacent timestamps and values. Random late-arriving data breaks compression runs.

Best practice: Buffer writes on the client side and batch in time order. If late data is unavoidable (sensor network delays, retry queues), batch and sort before writing.

Single-node fits: Write throughput under 500k points/second, storage under 10TB, query latency not critical for all queries. Single-node InfluxDB handles millions of series with proper tag cardinality management.

Signs you have hit single-node limits: Write latency p99 climbing despite batching. Query latency p99 degrading even on optimized queries. Disk I/O saturation (high wait times). Memory pressure causing OOM kills. Specifically for InfluxDB: series cardinality exceeding 10 million per node.

Cluster triggers: Writes consistently above 500k pts/s. Need for read replicas for query parallelism. Storage needs above 10TB on a single volume. Need for cross-node query distribution. HA requirements that demand redundancy.

InfluxDB cluster: Uses shard groups distributed across multiple data nodes. Query engine distributes work across nodes. Higher operational complexity but linear scaling.

TSM compaction: InfluxDB merges small TSM files into larger, more compressed files. Runs continuously in background. Compaction levels: level 1 (small files merge), level 2 (larger files), level 3 (full compaction). Tuning: set max-concurrent compactions to control I/O impact. Compaction takes priority over queries — high compaction activity slows reads.

TimescaleDB chunk compression: TimescaleDB uses PostgreSQL native compression on chunks older than a configurable interval. Controlled by timescaledb.compression policy. Compressed chunks use the TIMESARDES format internally.

Observable misconfiguration signs: TSM files growing too large (>2GB default limit, causes "max points per timestamp exceeded" errors). WAL growing unbounded (compaction cannot keep up). Query latency spikes correlate with compaction activity (I/O contention).

The problem: Irregular sampling creates gaps in data. Some sensors report every second, others every hour. Some go offline for days and then resume. Queries that aggregate across time buckets return empty buckets for sensors with no data — causing jagged time series and confusing visualizations.

Fill strategies: Use gap filling functions. In InfluxDB: FILL() with options like linear interpolation, null, previous value, or a constant. In TimescaleDB: time_bucket_gapfill() combined with locf() (last observation carried forward) or interpolate().

Schema design for offline sensors: Store last known state as a separate measurement. Query last value plus current reading and merge in the application layer. This avoids null gaps in dashboards.

Query performance: Gap filling adds computation cost. For high-volume irregular data, precompute filled series during downsampling rather than filling at query time.

InfluxDB CQs: Execute on a schedule defined in the CQ definition (e.g., every 5 minutes, every 1 hour). The query runs against the current state of the database at execution time. If the CQ fails, it logs an error but continues running on the next schedule. CQs do not track state between executions — each run is independent.

TimescaleDB continuous aggregates: Implemented as materialized views with background refresh policies. TimescaleDB tracks what data is materialized and only recomputes delta changes since the last refresh. This is more efficient than full recomputation. Failure handling is baked into the refresh job — if it fails, it retries on next refresh window.

Resource consumption: InfluxDB CQs run as foreground queries during their schedule — they compete with user queries for resources. TimescaleDB continuous aggregates run as background jobs with configurable priority.

Failure visibility: InfluxDB CQs require monitoring logs for errors. TimescaleDB continuous aggregates have timescaledb_information.job_errors view for error visibility.

Architecture: Hub-and-spoke with eventual consistency. Each region has a local InfluxDB or TimescaleDB instance receiving sensor data. Local instances handle real-time queries and dashboards for that region. Data is replicated to a central aggregation cluster using the database's replication features (InfluxDB's Enterprise replication or TimescaleDB's logical replication to a read replica).

Cross-region queries: The central aggregation cluster receives replicated data and handles cross-region analytics. For InfluxDB, you would use Federation to query across instances. For TimescaleDB, read replicas can be set up in different regions and queried with foreign data wrappers or application-level aggregation.

Write path optimization: Sensor writes go to local instance only (< 10ms latency). Replication to central is async (eventual consistency, acceptable for analytics). If local instance goes offline, sensors buffer locally and replay when connection restores.

Conflict resolution: If you need strong consistency, use a distributed TSDB like QuestDB or TimescaleDB with Citus. Otherwise accept eventual consistency with timestamp-based conflict resolution (last write wins per point).

TimescaleDB approach: Use PostgreSQL row-level security (RLS). Add tenant_id as a column and create a partitioned hypertable by tenant_id alongside time. RLS policies filter data at the query level — CREATE POLICY tenant_isolation ON measurements FOR ALL USING (tenant_id = current_user).

Performance implications: RLS adds policy evaluation overhead on every query. For high-volume multi-tenant workloads, this can slow queries by 10-20%. Better approach: use separate hypertable partitions per tenant (TimescaleDB supports spatial partitioning via partitioning_param). Queries hitting a single tenant partition skip other tenant data entirely — no policy overhead.

InfluxDB approach: Use InfluxDB organizations and buckets. Each tenant gets an organization with quota limits. InfluxDB enforces isolation at the API level. Simpler but less flexible than PostgreSQL RLS.

Alternative for strict isolation: Separate database per tenant. Maximum isolation, maximum operational complexity. Only worth it for high-security tenants or small tenant counts (dozens, not thousands).

Write buffering options: Buffer in memory using a queue (in-process or external like Redis or Kafka). If the TSDB is overloaded and cannot accept writes, the buffer accepts new data up to its capacity. When the TSDB recovers, the buffer drains into the database.

Backpressure signals: Monitor write acknowledgment latency. If writes start queuing in the TSDB WAL (observable via WAL growth in InfluxDB), you are approaching capacity. Set write latency SLOs and trigger backpressure when p99 exceeds threshold.

Preventing data loss: The WAL is your safety net. In InfluxDB, data is acknowledged after the WAL persists, not after TSM write — so as long as WAL is growing (data being persisted), you have durability. If WAL growth slows or stalls, you are losing data. Use show stats to monitor writeBytesOK and pointsWrittenOK.

Consumer lag monitoring: If using Kafka as a buffer between sensors and TSDB, monitor consumer lag. If Kafka consumer falls behind producers, you are building up backlog. Alert on consumer lag exceeding defined thresholds.

QuestDB advantages for tick data: Columnar storage optimized for analytical queries on large datasets. Uses vectorized execution for aggregations. SQL compatibility means easier integration with existing BI tools. Designed for Kafka ingestion with native Kafka support. Handles 100k+ pts/s with sub-millisecond latency on aggregated queries.

InfluxDB advantages: Mature ecosystem with Telegraf for collection, Grafana for visualization, Flux for complex data transformation. Native retention policies and continuous queries. Better for pure time-series workloads with simpler query patterns.

Decision factors: If your queries are primarily aggregations over time windows across millions of rows (typical for financial analytics), QuestDB's columnar engine will outperform InfluxDB's TSM. If you have complex per-point transformations or need the InfluxDB ecosystem, InfluxDB wins.

Operational maturity: QuestDB is younger and less battle-tested at massive scale compared to InfluxDB. If you need 24/7 enterprise support and proven production deployments at scale, InfluxDB has the track record.