Flespi solves the hardest problem in telematics — turning two hundred device protocols into clean JSON — and deliberately does not solve the next one. It is a gateway, not an archive. This is what to do about the gap.
What flespi is and is not
A flespi channel terminates device connections, parses the protocol, and stores the parsed messages in a buffer: 100 MB on a free account and 10 GB on a commercial one, for 30 days.
That is a buffer, not a database. It is exactly the right design for a gateway — it means a consumer of yours can go down for a weekend and catch up — and it means flespi is not where your history lives. After thirty days it is gone, and it was never queryable the way a business needs to query it: no joins to your vehicle table, no aggregation across months, no SQL.
So anyone using flessi seriously ends up building or buying the layer underneath it. The only question is which.
Getting data out
Three mechanisms, and the choice matters less than people think.
Streams. Flespi forwards parsed messages to another platform, including as HTTP POSTs of JSON. Push-based, no polling, and flespi handles retries from its buffer if your endpoint is briefly down. This is the one to use unless you have a reason not to.
MQTT. Subscribe to the message topics and receive them as they arrive. Attractive if you already run a broker and want fan-out to several consumers. More moving parts to operate.
REST polling. Ask for messages since a cursor. Simplest to write, worst to run: you own the cursor, the retry logic and the gap detection, and gaps are exactly the failure mode you will not notice.
Take the stream. The buffer behind it is the feature you are actually buying.
Where to put it
Now the real decision. Four options, honestly ranked by how far they get you.
Postgres alone
Start here if you are unsure. One database, SQL, PostGIS if you need real spatial work, joins to your vehicles and customers. It is the right first move and it works for a long time.
What eventually pushes you off it is volume: positions are append-only, arrive constantly, and are read in ranges, which is the workload a row store is worst at. The table becomes the largest object you own and the analytical queries start competing with the transactional ones.
Postgres with TimescaleDB
Keeps everything above and adds time-series partitioning and compression — 2:1 to 3:1 on this kind of data. One database, familiar tooling, meaningfully more headroom. If operational simplicity is your priority, stop here; this is a genuinely good answer.
A columnar store beside Postgres
Positions to something like ClickHouse, everything relational left in Postgres. Better compression — we measured about nineteen bytes a position — and range scans that read two columns rather than fifteen.
The cost is a second database to back up, monitor and upgrade, and a data model split you have to hold in your head. Worth it when position volume is the product rather than a side effect.
A platform that already did this
Which is what Routly is. Flespi in, Postgres and ClickHouse out, plus the layer that turns positions into things a business uses — trips, fuel events, driver scores, scheduled reports.
What you are actually building if you build it
Worth costing honestly before you decide, because “just write the positions to a table” is the first two days of a project that is not two days long.
- Idempotent ingest. Streams retry. You will receive duplicates and must not double-count.
- Device-to-vehicle mapping. A flespi device identifier is not your fleet number. Something has to hold that, and handle a device moving between vehicles.
- Sensor normalisation. Every integrator names fuel level differently, and units vary. This is the tedious, unavoidable part.
- Trip detection. Ignition, movement, dwell thresholds. Easy to write badly; the resulting trips are what your customers will argue about.
- Retention. Something has to expire raw positions or the disk fills. Partition by time so it is a drop rather than a delete.
- Backfill. When your consumer is down for six hours, someone has to notice and replay from the buffer.
- Monitoring the silence. The failure mode of ingest is nothing arriving, which looks identical to a quiet fleet. Alert on absence, not on errors.
None of it is hard. All of it is a quarter, and it is the same quarter every telematics team spends.
If you are already on flespi
The shortest experiment: create a stream pointed at a Routly instance’s /api/webhook/flespi endpoint with a shared secret, send three devices to it, and compare what appears against what flespi shows you. Nothing about your channels, devices or existing consumers changes — a stream is additive, and you can delete it afterwards.
If you are on flespi because you are on Wialon, there is a shorter path still: the Wialon retranslator into a flespi channel, which reaches the same place without touching a device.
Frequently asked
Does flespi keep my data if I stop paying?
The buffer is 30 days on a live account. Treat the gateway as transport, and keep the archive somewhere you control — which is rather the point of this article.
Can I use flespi and Traccar together?
Yes, and some fleets do: flespi for the devices it handles best, Traccar for the long tail. Both can forward to the same endpoint.
What does a stream cost?
Flespi publishes its own pricing and bills by device. We have no commercial relationship with them.
Is MQTT better than HTTP for this?
Not for a single consumer writing to a database. MQTT earns its complexity when several independent systems need the same messages.
How much disk should I plan for?
At nineteen bytes a position, a vehicle reporting every 30 seconds for eight hours a day is about 6.5 MB a year. Two thousand vehicles is roughly 13 GB a year. Plan for the queries, not the bytes.
