FleetSQL started with a frustration I lived with for years, and a fascination I never quite shook off. The data was always there, sitting on the screen right in front of me, but turning it into something I could actually use was another matter entirely. What follows is the story of how a personal obsession with telematics reports turned, slowly, into a product.
It started with the reports
For a long time I was the person who loved the reports. I worked closely with Wialon’s reporting and analytics, and I genuinely enjoyed that side of the platform. I could name the report templates from memory, list the columns, and tell you what each one could and could not show. Reports were the part of the work I cared about most.
The trouble was that customers kept telling me how hard it was to get the data out, and back then I did not really understand why. When they raised it, I would repeat what the developers had told me, that it could be done through the API, as though that settled the matter. “API” was a kind of magic word to me, something I trusted to work without ever having tried it myself. It was only later, once I sat down and attempted it, that I saw how difficult it really was. Looking back, I do not think I was empathetic enough to the partners who had been struggling with exactly this, and that realization is part of what kept me going.
What customers kept asking for
Working alongside solution providers, I heard the same request again and again. People did not want to open a report, scroll through the rows, and work out the answer for themselves. They wanted the answer directly: a few numbers, a KPI, a simple state such as whether a vehicle was inside or outside a geofence. That piece of feedback came back so often that it slowly pulled me toward the data itself, and toward the question I had been avoiding all along, which was why getting to it was so hard.
Little by little, from a script to a product
So I started small. I approached the reports from the API side for the first time, beginning with the simplest things, like reading a unit’s properties and listing the units. Bit by bit the real shape of the work revealed itself. You set up a report, run it, export it, pull the data out of different tables and rows, and then reshape all of it into something organized. The limitations I had heard customers complain about for years finally became concrete, and for the first time I understood them from the inside.
What began as curiosity turned into a Python script. The script did one job, then another, and every time a customer gave me feedback or I ran into a new limit, I extended it a little further. Almost without deciding to, the script kept growing. Today FleetSQL is no longer a script at all. It has become a proper backend service, with its own console interface and a database behind it, and it is still evolving with every platform and every dataset we connect to it.
The same problem everywhere
At some point I wondered whether this was a Wialon-only problem. It was not. Other fleet platforms, telematics systems, and connectivity providers all had the same gap, where the data was visible but stubborn to extract and analyze. So we kept building and added one integration after another, and the same pattern showed up every time.
Why nobody had solved it
The reason the gap survives becomes obvious once you look at who is doing the work. If you are an integrator, your days go into installing solutions, testing hardware, handling installations, and running training. If you are a fleet operator, you are focused on winning contracts, learning the business, keeping rentals efficient, and deciding what to buy and sell. Neither side has the time or the resources to build a data-fetching mechanism of its own, and so the data simply stays where it is.
That is the gap FleetSQL fills. Nothing is locked away and nothing is hidden. You get everything you already see on your platform, only structured, queryable, and yours. In the end it became a place where your fleet data is organized and owned by you, rather than trapped inside someone else’s interface.
Data ownership, and learning by experiment
Some of this came together for me at the Gurtam Telematics Conference, where I ran a panel on exactly this subject.
We kept circling back to a single idea: owning your data is the key to insight. Data is not perfect, and every now and then it points you toward the wrong decision. But without it you are working blind, unable to see what is happening or what your own choices are actually doing.
That is also why I am wary of advice that arrives pre-packaged. “Set up these alerts and you will cut this or that, the surveys prove it” rarely survives contact with a real fleet. Every operation is different, and the only honest way to improve one is to try a change against your own data, measure what actually happens, and keep what works. You cannot do any of that with data you cannot reach.
What FleetSQL does today
FleetSQL connects to your fleet or telematics platform and turns what you already see there into clean, structured tables you can query, join, and build on. There is no extraction code to write and no pipeline to maintain on your side, so the data simply arrives in a form you own and can work with. If your numbers feel locked inside someone else’s interface, that is the problem it was built to solve.
See what FleetSQL can pull from your platform →