Let's track stable TimescaleDB & PostgreSQL versions for Traccar

Hi everyone,

I am currently architecting a new Traccar-based environment for precision agriculture. Unlike standard vehicle tracking, my setup involves high-precision GNSS modules (u-blox ZED-F9P/R) delivering high-frequency telemetry (1Hz+).

To avoid the common "massive table" bottlenecks down the road, I’ve decided to skip standard and start directly with TimescaleDB for my position logging.

My Project Setup:

• Ubuntu Server: Ubuntu 24.04.4 LTS with Docker (Hetzner)
• Traccar Image: "traccar/traccar:6.12.2-ubuntu" (Fresh Install)
• Database Image: "timescale/timescaledb:2.36.3-pg16" (Alpine-based)
• Tracker Hardware: u-blox ZED-F9P/R (RTK precision)

Why I’m choosing TimescaleDB for Day One:

1. Performance at Scale: I want to utilize Hypertables from the start to ensure fast queries even when we reach billions of points.
2. Native Compression: Agricultural data is repetitive; I want to leverage Timescale’s compression early to keep storage costs low.
3. Advanced Analytics: I’m planning to use the included pg_stat_statements for performance monitoring and pgvector for future spatial AI tasks.

Questions for the community:

Since I am starting with a clean slate:

• Are there any specific Traccar configuration tweaks you recommend when using TimescaleDB instead of standard PG?
• Has anyone experienced issues with Traccar's automatic schema updates when the underlying tables are managed by TimescaleDB?
• Which chunk interval (partitioning size) have you found most effective for the positions table with high-frequency (1Hz) data?

Database Images: I am currently testing the stability across different versions using a custom Dockerfile build process:

• timescale/timescaledb:latest-pg16 (Primary test candidate)
• Early-stage testing with PostgreSQL 17 and experimental 18 builds to ensure long-term compatibility with upcoming Traccar releases.

We use timescale/timescaledb:latest-pg16 on pretty much all of our new server. It worked really well so far. We don't specify chunking, so I believe it uses the default 7 day, which hasn't been a problem.

Note that using compression might cause issues for you. That's because Traccar might need to references positions from old chunks for devices that haven't reported new data. This will be really slow if you enable compression.

Hi Anton, thanks for your advice and the information.

However, this doesn’t fully answer my question. When you start with "timescale/timescaledb:latest-pg16" on November 30, 2025, it pulls a specific TimescaleDB version (for example 2.23.0 at that time). If you pull the same image again later, without explicitly upgrading the extension inside the container, the database may still be running that older TimescaleDB version rather than a newer one (for example 2.26.3).

I’m still at the beginning of my project, so I might be misunderstanding something here. But if my assumption is correct, it would be very helpful to maintain a list of stable version combinations and clear recommendations on when it’s safe to upgrade for production environments.

Latest should be a stable version. I don't see a new to be more specific than that.

I think Timescale should be pretty much the standard for any deployment.