Everything that speaks PostgreSQL already speaks FleetSQL

Power BI, Metabase, Grafana, Tableau, Superset, Looker and every other BI tool ships a PostgreSQL connector, so the integration is a form with five fields rather than a project. Point the tool at the database, build against w_evnt_trips, the other event tables and w_prop_unit, and refresh on whatever schedule the tool already uses.

Nothing in the database favours one of them. The screenshot on this page is Grafana because it is the board we can show you running, not because it is where the data belongs — a fleet that reports in Power BI points Power BI at the same host and gets the same numbers, since the numbers are SQL rather than a feature of a dashboard tool.

Because the data is a database rather than a report export, drill-down works the way analysts expect: a chart of distance by month clicks through to the vehicle, then to the day, then to the individual trips and speeding events behind the number — without anyone re-running an extraction to answer the follow-up question.

Power BI is where most fleets already report, so it is worth being concrete. In Power BI Desktop it is Get Data → Database → PostgreSQL database, then the host and database name exactly as the console shows them and the read-only role issued for the tool. The tables arrive in the navigator under the public schema: w_prop_unit, the w_evnt_* events, and any w_rprt_* tables for the report templates you enabled.

The one choice worth thinking about is Import against DirectQuery. Import copies rows into the model, which is fast to slice and refreshes on the schedule Power BI already runs — the sensible default for a few million trip rows. DirectQuery leaves the history in Postgres and pushes each visual's query down to it, which suits three years of events you would rather not duplicate into a model. Both read the same tables, and neither needs anything installed on our side.

What the model can then do is the actual point: fleet data joins the rest of the business inside Power BI — cost centres, customer contracts, the ERP extract somebody already publishes. That join is what a telematics reporting screen cannot do at any price, and it is the reason the data has to sit in a database you can point a tool at.

History in a database is what makes forecasting and anomaly detection possible at all — a report export is a snapshot, and a model needs a series. With up to three years backfilled on the first run, a notebook has something to learn from on day one.

Every serious agent framework and MCP server speaks PostgreSQL, which makes a FleetSQL database directly askable in plain language: "which trucks idled more than three hours yesterday" becomes a query the agent writes, runs and explains. No custom tool wrapper, no scraping a reporting UI.

The practical requirement is a schema an agent can reason about, which is why table names carry their own provenance — w_prop_, w_evnt_, w_rprt_ — and why every database ships a _meta_data_sources registry an agent can read first: what exists, at what grain, last synced when. A wide, opaque schema is what makes text-to-SQL hallucinate; a documented, self-describing one is what makes it useful.

n8n, Zapier, Airflow, cron — anything that can run a query on a schedule can turn a row into an action. A drain over twenty litres becomes a webhook into your ticketing system; a vehicle whose last_message_time has gone quiet becomes a maintenance task; a vehicle crossing a speeding threshold becomes a line in the weekly review.

Because the alert logic lives in SQL rather than inside a telematics platform's notification builder, it is reviewable, version-controllable and testable against history — you can run this month's rule against last year to see how often it would have fired.

The highest-value integration is usually not a tool at all: it is the table you create next to ours. Fuel card transactions, customer contracts, ERP cost centres, maintenance records — once they sit in the same database as the telemetry, questions that used to require three exports and a spreadsheet become one query.

That is also the point at which fleet data starts answering commercial questions rather than operational ones: cost per delivery, profitability per customer, the real cost of an empty return leg. Asset Track builds those joins as a service when the sources are messier than a CSV — see Wialon integration services.