InfluxDB

InfluxDB has changed query languages across major versions, so AddisDB supports both. The editor has a language toggle: InfluxQL by default, which covers the large 1.x and 2.x installed base, and SQL for InfluxDB 3.x. Switching it points the query at the right endpoint — your editor text stays clean.

Who it is for

InfluxDB is purpose-built for metrics and events: high write throughput, retention policies that expire old data automatically, and downsampling so a year of history does not cost what a year of raw points would.

Its data model is worth internalizing before you write a query. A point has a measurement, tags (indexed strings you filter and group by), fields (the actual values, not indexed) and a timestamp. Filtering on a field rather than a tag is the usual reason a query is slow, and putting something high-cardinality in a tag is the usual reason the database is.

It fits infrastructure and application monitoring, IoT and sensor fleets, and any pipeline already built on Telegraf.

Set up the server

1. InfluxDB Cloud: create an account, then a bucket. Under API Tokens, generate a read token and copy it.
2. Copy your cloud region host — it serves HTTPS on port 443.
3. Local: docker run -p 8086:8086 influxdb:2, then complete setup at localhost:8086 to create an org, bucket and token.
4. For a 1.x server, you will have a username and password rather than a token.
5. Know which major version you are on — it decides which query language will actually answer.

Connect from AddisDB

1. New Connection → InfluxDB under Timeseries. Port prefills to 8086.
2. Enter the host, and put your database or bucket name in the Database field.
3. For 2.x and 3.x, paste the API token into the API key / token field and leave Username blank. For 1.x, fill in Username and Password — AddisDB uses HTTP basic auth when a username is present.
4. For InfluxDB Cloud, set the port to 443 and SSL mode to require.
5. Test, then Save.

On 2.x, InfluxQL reaches a bucket only if the bucket is mapped to a database-and-retention-policy name. Without that mapping the endpoint answers but finds nothing — which reads as an empty database rather than a configuration gap.

Choosing a query language

The toggle above the editor picks the language. InfluxQL runs against the classic query endpoint; SQL runs against the 3.x SQL endpoint. Results from either shape are flattened into the same grid.

-- InfluxQL
SELECT mean("usage_idle") FROM "cpu"
WHERE time > now() - 1h GROUP BY time(1m)

-- SQL (InfluxDB 3.x)
SELECT date_bin(INTERVAL '1 minute', time) AS t, avg(usage_idle)
FROM cpu WHERE time > now() - INTERVAL '1 hour' GROUP BY t

Always bound the time range. Without a time predicate both languages will happily scan the entire retention period, which on a metrics database is every point ever written.

SHOW MEASUREMENTS, SHOW TAG KEYS and SHOW FIELD KEYS are the InfluxQL equivalents of reading a schema, and they are the quickest way to orient yourself in a database somebody else set up.

What AddisDB gives you

• Both query languages in one connection, with the endpoint chosen for you.
• The Chart view — a result with a time column renders as a time-series chart automatically.
• Measurements listed in the sidebar so you can see what is being written.
• Read-only enforcement — mutating statements such as DROP, DELETE, CREATE and ALTER are rejected.
• Query tabs and history, and ⌘K search across every connection.