Connections
Every other page in these docs is about pushing telemetry to Plexus. This section is about the other direction: querying data that already lives in a database you run, next to what you store in Plexus Time Series.
There are two ways data reaches Plexus, and it is worth knowing which one you are on, because they behave differently.
| What it is | Where the data lives | |
|---|---|---|
| Devices push | The Python SDK, HTTP, or Prometheus remote_write | In Plexus |
| A database | A connection string and your own SQL | In your database; queried on demand |
A device is something you send data to us from. A connection is something we read from. Both appear in the same lists, share one naming scheme, and can be put on the same dashboard — the difference is only which way the data travels.
What a connection needs
Nothing installed on your side. A connection is a host, a credential, and
read access. Plexus only runs SELECT queries on a connection.
Available now
Six databases connect the same way: PostgreSQL, TimescaleDB, ClickHouse, MySQL, QuestDB and InfluxDB. Pick the type and paste a connection string. There is nothing to configure beyond the string.
On PostgreSQL, TimescaleDB, ClickHouse, MySQL and QuestDB you write SQL. InfluxDB is partial: Plexus reads buckets and charts them, but SQL panels don't apply (details).
Each one has its own page on the Plexus site: PostgreSQL and TimescaleDB, ClickHouse, QuestDB and MySQL.
Files and other ways in
PX4 flight logs (ULog) and CSV files are not connections. You import a file
into a device, and its readings are stored in Plexus with their original
timestamps, like anything else that device sends. On Devices, click
Add Device and choose Log file. File import needs Pro; on Free
the app answers 402. More on
PX4 flight logs.
Services that already speak Prometheus send with remote_write
(details). That data is
pushed and stored in Plexus, like a device.
Alerts go out by Slack and email, and by phone to the people on an on-call ladder.