I need a time-series database that can keep 24 months of data and still query recent windows quickly

For 24 months of retention plus fast recent-window queries, you’ll usually want a time-series database with:

• strong partitioning / chunking by time
• compression for older data
• good indexing on recent data
• retention policies / downsampling
• optionally tiered storage if the data volume is large

Good options

1. TimescaleDB

Best if you want SQL and PostgreSQL compatibility.

• Great for time-based partitioning via hypertables
• Compression for older chunks
• Retention policies and continuous aggregates
• Recent windows stay fast if you keep indexes on the hot data
• Easy for analytics + relational joins

Best for: teams already using Postgres or needing SQL.

---

2. InfluxDB

Good for high-ingest metrics and time-series workloads.

• Built specifically for time-series
• Supports retention rules and downsampling
• Efficient for recent time-range queries
• Works well for observability/metrics use cases

Best for: metrics, monitoring, event streams.

---

3. ClickHouse

Best if you need very fast analytics over large historical datasets.

• Excellent compression and scan speed
• Handles long retention well
• Very fast for aggregations across large ranges
• Needs more care in schema and data modeling than TimescaleDB

Best for: heavy analytical queries, dashboards, large volumes.

---

4. QuestDB

A simpler, fast time-series database.

• Optimized for high ingest and low-latency queries
• Good for recent-window access
• SQL-like querying

Best for: simple time-series workloads where speed matters.

---

Rule of thumb

If your main requirement is:

• Fast recent queries + SQL + 24 months retention → TimescaleDB
• Metrics/observability → InfluxDB
• Very large-scale analytics → ClickHouse

Important design tips

To keep recent windows fast for 24 months of data:

1. Partition by time
2. Index on (device_id, timestamp) or your main query dimensions
3. Compress older partitions
4. Keep only recent data uncompressed
5. Use downsampling for older periods
6. Avoid huge “all-time” scans unless necessary

If you tell me:

• your data volume per day,
• query pattern,
• and whether you need SQL,

I can recommend the best fit more precisely.