How OpenVTS engineered whole-fleet live tracking without freezing""How OpenVTS engineered whole-fleet live tracking without freezing

Rajat Yadav — Tue, 20 Oct 2026 09:13:00 +0000

A live fleet map feels magical at 30 vehicles. It feels broken at 3,000. The same map, the same code, the same server — and suddenly the markers stutter, the tab chews through memory, the browser warns "page unresponsive," and dispatchers stop trusting what they see. Nothing crashed. It just stopped being live.

The instinct is to blame the map library. The real cause is almost always the pipeline feeding it: how position updates travel from thousands of devices to thousands of screens, and how much work gets repeated on every single packet.

OpenVTS is a self-hosted GPS tracking and fleet-management platform. This is a breakdown of how it engineered the path from thousands of devices to one live map: the design decisions that let it show an entire fleet at once without the tab falling over. The mechanisms are general, but the specifics here are the ones OpenVTS documents — so we can point at real behavior instead of guessing.

First, the honest framing

Whole-fleet live is the hard mode, and the industry shows it from several directions. Some platforms set a ceiling — one commercial product's own docs cap tracking at 3,000 entities at once. Others publish concurrency limits, such as a handful of simultaneous map traces and a small number of simultaneous API requests per session. And some systems attempt the whole fleet and fall over: in one widely used open-source tracking server, an operator running roughly 2,700 devices described the admin view going "extremely slow and often freezes or becomes unresponsive… when trying to display all devices on the map at once," even on high-spec servers (32 GB RAM, 8 vCPU). At about 1,500 devices, another operator reported the UI "keeps acting up," with buttons that did not click and panes that took "forever to move." The maintainer's diagnosis was not the server: "Your browser won't be able to handle that amount of data. It has nothing to do with server configuration." In the 2,700-device thread, the change he shipped was a web build with "more aggressive throttling."

That statement is true — for a naive design. The point of this article is that naive is a choice, and a different set of design decisions produces a different curve.

Why one map plus thousands of vehicles is genuinely hard

Four properties make fleet-scale live tracking harder than it looks:

The load is constant, not bursty. A fleet of 3,000 vehicles reporting every 30 seconds is ~100 packets/second, forever. At 10-second intervals it's ~300/second. You're not surviving a spike; you're sustaining a baseline.
Fan-out is asymmetric. One device produces one update. One dispatcher screen consumes all of them. Add a manager watching the whole fleet and a customer watching their 40 vehicles, and the same packet has to reach very different audiences.
The browser is a participant, not a spectator. Every moving marker is DOM work, layout work, and memory. Thousands of animated markers will bring a laptop to its knees regardless of how fast your server is.
"Now" and "then" are different workloads. "Where is vehicle 812 right now?" is a tiny, hot, constantly-overwritten question. "What did the fleet do last quarter?" is an enormous, cold, append-only one. If both hit the same path, the live view pays for the report.

Path	What it holds	Who reads it
Live state	Latest position, speed, ignition, last-seen — hot, small, overwritten	Dispatcher, manager, and customer screens
History	Append-only positions and events — cold, large, compressed	Reports, replay, investigations

The same packet feeds both: ingest → decode → live state and history. Live screens read deltas from the first; reports and replay read the second. The live path does not go through the history store.

Almost every freeze traces back to ignoring one of those four. We'll take them in order, and for each one look at how OpenVTS documents handling it — then what that choice costs.

Mechanism 1: push deltas, not polls

The first prototype of almost every tracking dashboard polls: each open tab asks the API "give me all vehicle positions" every 5–10 seconds.

It's fine for a dozen vehicles and a couple of tabs. Then the arithmetic turns on you:

Traffic grows linearly with open tabs, not with actual movement.
A parked vehicle that hasn't moved in six hours still costs the same as a moving one.
Every viewer re-downloads the full fleet state, most of which hasn't changed.
The floor on latency is your poll interval — 10 seconds is forever when a truck is about to miss a loading window.

The fix is to flip the direction: push, don't pull. Hold one persistent connection per client — WebSocket, or server-sent events for streams — and when a packet arrives, push only the vehicles that changed.

Naive pull	Push deltas
Each tab asks for the full fleet every 5–10 s	One persistent connection per client
Traffic grows with the number of open tabs	Traffic grows with what actually changed
The database serves the same answer to every viewer	The server reads the change once and fans it out
Latency floor is the poll interval	Latency is bounded by the device's reporting interval

This is exactly the behavior OpenVTS documents. Its map guide says that after the initial load, live socket updates "apply only to vehicles whose telemetry has changed. This avoids rebuilding the complete Map whenever one device sends a new packet." The initial load itself is progressive: large fleets arrive in pages, so the map becomes usable before every record has landed.

That single change fixes a second problem you may not have noticed. With polling, 200 viewers reading state every 5 seconds is a query load problem. With push, the server reads the changed state once and fans it out.

The tradeoff: push means you now own connection lifecycle — auth, reconnect, subscription scope, ordering, and backpressure. That's real work. It is still less work than serving a full fleet to every tab forever.

Mechanism 2: live state is not the database

Here's the trap. Even after you switch to push, it's natural to answer "current position" by querying the database — it's the obvious source of truth.

It isn't the right source for now. Position updates overwrite each other constantly. The history table is optimized for "what happened across time," not for "the latest value of 3,000 rows, asked hundreds of times a second." Querying it for the live map means:

You read the same rows over and over, once per viewer — 500 viewers × 500 vehicles is 250,000 row reads per poll cycle, for one answer.
Report scans and live reads contend for the same engine.
The live map's latency depends on the database's worst moment, not its average.

The design that scales separates current state from history:

Current state lives in a hot, in-memory store — keyed by vehicle, holding the latest position, movement status, ignition, connectivity. It's tiny, it's overwritten constantly, and losing it is a blip that rebuilds from the next packet.
History lives in a time-series store, append-only, compressed, partitioned by time, so a six-month report can prune to the right chunks instead of scanning everything.
Geography — geofences, "vehicles near here," reverse-geocoded addresses — gets its own spatial index so it never lands on the hot path.

In OpenVTS this maps onto the documented stack: Redis provides "live vehicle status, latest location information, queues, [and] current state"; TimescaleDB holds history; PostGIS handles geospatial work. The health API reflects the same separation at the database level — /health/databases reports primary, logs, and address independently, with their own response times, which is consistent with these stores being operated separately rather than as one contended engine. Redis is explicitly documented as private (port 6379, never public).

The device sends a position packet.
Ingest decodes it and overwrites the vehicle's latest entry in live state — a tiny write.
The same ingest appends the point to history — append-only.
Live state pushes a delta for that one vehicle to connected map clients.
Only when a user asks for history or replay does the client read the time-series store.

The payoff is that the live map never asks the database "where is everyone." It asks memory, and memory is fast by construction.

The tradeoff: you now have two writes and two failure modes per packet, plus a cache that can be stale or empty after a restart. That's why reconnect handling matters — the client has to recover live state without duplicating markers, and the history store stays independent so nothing is lost when memory is.

Mechanism 3: the client redraws what changed, and bounds what it draws

Now the client side, where the freeze becomes visible.

If a single new position triggers a full rebuild of the vehicle set and a redraw of the whole map, you've built a system whose cost is proportional to fleet size × packet rate — the worst possible curve. Three thousand vehicles each reporting every 30 seconds, each packet redrawing 3,000 markers, is 100 full redraws per second. That's the "page unresponsive" dialog.

Two rules fix it.

Rule 1 — update incrementally. A new packet changes one vehicle. Update that one marker and the things that depend on it, and leave the map alone. OpenVTS documents this as "incremental marker updates" and recalculates status "without complete reload."

// Illustrative shapes — not the platform's published socket schema.

// ❌ full fleet on every tick — cost grows with fleet size
{ "vehicles": [ { "id": 1, "lat": 12.34, "lng": 56.78 }, /* … 2,999 more */ ] }

// ✅ delta — bounded by what actually changed
{ "changed": [ { "id": 812, "lat": 12.3456, "lng": 56.7890, "speed": 63, "heading": 210 } ] }

On the client, reconcile by identity instead of rebuilding: keep a map keyed by vehicle id, update only the entry that arrived, and leave every other marker untouched.

Rule 2 — bound the work the browser can be asked to do. Even incremental updates get expensive if every vehicle is an individual animated DOM node at every zoom level. OpenVTS documents the standard toolkit:

Marker clustering — group nearby vehicles into one marker with a count, splitting as you zoom in. A selected vehicle is kept outside the cluster so it stays individually visible.
Suppression at scale — vehicle name labels off at wide zoom (they overlap and eat layout), and the move "ripple" animation off when many vehicles are moving at once.
Progressively loaded state — counts and markers can appear while more pages are still loading, rather than blocking the first useful frame.

The general engineering is well known: clustering is effectively mandatory for large marker sets, viewport-aware clustering keeps cost tied to screen area rather than fleet size, and rendering many markers as fewer optimized elements beats one DOM node per marker. The exact thresholds vary by library and hardware; measure yours.

The tradeoff: clustering hides individual vehicles. That's correct for an overview and wrong when you're chasing one truck — which is why selected-marker isolation and a cluster toggle matter.

Mechanism 4: every request is bounded

A subtler freeze comes from the "then" workload sneaking into the "now" path.

Two common offenders:

Reverse geocoding on the render path. Turning coordinates into a human address is expensive. If every live marker triggers a geocode, you've welded an external dependency to your frame rate. OpenVTS lists cached addresses as part of its large-fleet behavior.
Unbounded history requests. "Show me the path for the last 30 days" can be millions of points. OpenVTS bounds this in several documented ways: paginated logs and events, point limits for Show Path and Replay, configurable history date limits, and a note that a preset longer than seven days cannot be handled as a single history request. The log view is also capped "to protect browser performance during long sessions."

The principle: never let a request's cost be unbounded. Bound it by time window, by point count, or by page cursor — and show progress while more pages load.

The tradeoff: users see partial data sooner and may need to page or narrow a range. That's a better failure mode than a frozen tab, but it has to be visible in the UI, or people assume data is missing.

Putting it together: how the pipeline actually runs

Here is the end-to-end path those mechanisms describe.

Write path: device → listener (per-protocol port) → decode and normalize → Redis (latest state) + TimescaleDB (append-only history) + PostGIS (spatial facts). The live path touches memory; the durable path appends.

Read path: live map ← socket deltas from Redis; history and replay ← backend API → TimescaleDB and PostGIS. The live read path does not go through the history store at all.

This is the part that makes the platform more than a map with a database behind it.

The Superadmin Map guide's "Large-Fleet Operation" list is essentially these decisions made explicit: progressive telemetry loading, cursor-based data pages, batched live telemetry, incremental marker updates, status recalculation without full reload, optional clustering, selected-marker isolation, cached addresses, paginated logs and events, point limits, and configurable history limits. There is also a small but telling detail — a short debounce when a vehicle's speed drops, so a single zero-speed packet doesn't flip its status on screen.

None of this is exotic. It is the unglamorous work of making every step bounded.

What still bites you

The mechanisms above remove the architectural cliffs. They do not remove the messy parts. A senior review should ask about these, and the docs acknowledge most of them:

Reconnect and backfill. Sockets drop. Devices buffer and resend. The client must recover state without duplicating markers or losing the selected vehicle. OpenVTS's own large-fleet test checklist includes "recovery after socket reconnection."
Late, duplicate, and out-of-order telemetry. Event time is not receive time. A device that was offline can flush hours of records on reconnect. If the live layer treats "received now" as "happened now," the map lies. Keeping history immutable and live state explicitly "latest accepted" is what prevents this.
Background tabs. Browsers throttle timers and animation frames when a tab is hidden. A map that looks fine in front of you can accumulate work in a background tab and stutter on return. Bound client queues, don't assume the tab is always active.
Batching latency. Batching live telemetry reduces per-frame work but adds delay. There is no free lunch; pick a window and measure the perceived lag.
Identical coordinates. Many vehicles parked in one depot share nearly the same point. Clustering helps, but the docs explicitly test "behaviour when coordinates are identical" for a reason.

Why the same design is also the cheap design

The decisions that keep the map smooth are the same ones that keep the bill down — they aren't separate problems:

Live reads from memory, not the database. The expensive engine isn't hit once per viewer, so you don't buy CPU to serve the same answer 250,000 times.
Deltas instead of full state. Bandwidth and client work scale with change, not fleet size.
Bounded history. Capped, paginated, windowed requests mean one curious user can't pin a core.
Clustering and viewport work. The client draws what's visible, not the whole world.

Then there's the commercial layer. OpenVTS is self-hosted and licensed by one-time capacity tier rather than a compulsory recurring per-vehicle fee within the tier you buy: free up to 50 vehicles, then Growth, Scale, and Enterprise bands. Growing from 200 to 2,000 vehicles doesn't multiply a monthly software line. The honest caveat: paid plans include one year of updates and support, and continued support/updates after that are optional and separate. Hosting, SIM/data, maps, messaging, and storage remain real operating costs. The software cost stops scaling per vehicle; your infrastructure bill still scales with what you actually run.

Prove it before you promise it

Capacity claims are worthless until measured. Every platform's "supports thousands of vehicles" is a hypothesis until you load-test the real path: real protocol, real reporting intervals, real retention, real users, real reports.

OpenVTS's own documentation is unusually direct about this. It gives a practical planning range of roughly 500–2,500 vehicles under moderate conditions (8 vCPU / 16 GB), and explicitly calls for load testing above ~2,500. That is a useful anchor — and a reminder that "thousands" is a hypothesis until you test it.

Two things make this practical with OpenVTS:

A documented large-fleet test checklist — total counts, progressive loading, search/filter response, marker smoothness, cluster expand/collapse, live HUD accuracy, log stream stability, replay loading, and specifically "behaviour when thousands of vehicles update simultaneously," "behaviour when coordinates are identical," and "recovery after socket reconnection." Those last three are where naive systems die.
A free device simulator — the Virtual GPS Device Farm spins up thousands of virtual trackers against your own server, so you can find the freeze in a test environment instead of in production. (That's its own deep-dive; see the companion piece on load-testing for the ingestion side.)

If you're evaluating any platform, that's the bar: can you generate thousands of moving devices and watch what breaks?

Honest limits

"Real-time" is capped by the device. If a tracker reports every 60 seconds, no platform can produce genuine one-second positions from data it never received. Freshness is an end-to-end property.
Clustering is a tradeoff. Grouping hides individual vehicles — fine for an overview, wrong when you're chasing one truck.
Docs describe behavior, not all internals. The architecture (Redis/TimescaleDB/PostGIS, socket deltas) is documented at the component level, not as source. Treat internals as inference, not fact.
Self-hosting moves responsibility to you. A poorly sized or unmonitored server will freeze regardless of how good the software is. These mechanisms remove the architectural bottlenecks; you still have to run the machine.

The takeaway: eight questions for any live fleet map

Before you build — or buy — whole-fleet live tracking, ask:

Does it push deltas, or poll the full fleet per tab?
Is current state served from a hot store, or re-queried from the database?
Does a single packet redraw one marker or the entire map?
Is history bounded by time window, point count, and pagination?
Is geocoding cached, or run on the render path?
Does the map cluster and viewport-filter when many vehicles share an area?
Is the selected vehicle isolated from clusters?
Can you load-test with thousands of real devices before you promise it?

Get those right and a whole fleet on one map stops being a party trick that dies at scale and becomes infrastructure you can run a dispatch floor on. Get them wrong and the freeze isn't a matter of if — just of when the fleet gets big enough.

References

OpenVTS platform — https://openvts.io
Route optimization — https://openvts.io/resources/documentation/user-guide/route-optimization
Landmarks Studio: geofences, POIs, and routes — https://openvts.io/resources/documentation/user-guide/user-landmarks-studio
Large-fleet map guide — https://openvts.io/resources/documentation/superadmin-guide/superadmin-map-complete-fleet-tracking-guide
API reference — https://openvts.io/resources/api-reference
GitHub organization — https://github.com/openvtsofficial
GPS device simulator — https://github.com/openvtsofficial/gps-device-virtual-farm

The public GitHub organization hosts the mobile application, the app builder, and the device simulator. The main platform is distributed as a licensed deployable build rather than as public source.

DEV Community: Rajat Yadav