Deploy InfluxDB time-series database on Ubuntu using Docker — high write throughput for IoT metrics, server monitoring, and Flux queries.
Grab the automated bash script from GitHub to follow along with the video.
wget https://raw.githubusercontent.com/mhmdali94/Docker/main/databases/influxdb/influxdb-ubuntu.sh
chmod +x influxdb-ubuntu.sh
sudo bash influxdb-ubuntu.shwget https://raw.githubusercontent.com/mhmdali94/Docker/main/databases/influxdb/influxdb-ubuntu.shchmod +x influxdb-ubuntu.shThe script installs Docker if needed, then deploys InfluxDB 2.x with built-in web UI.
sudo bash influxdb-ubuntu.shOpen browser and navigate to:
http://<your-server-ip>:8086Complete the setup wizard — create your organization, a bucket for your metrics, and generate an API token for your data sources.
# Via CLI inside container
docker exec -it influxdb influx setup \
--username admin \
--password YourPassword \
--org MyOrg \
--bucket metrics \
--force| Port | Purpose |
|---|---|
| 8086 | InfluxDB Web UI + API |
InfluxDB is a purpose-built open-source time-series database optimised for storing and querying metrics, events, and real-time analytics at high write throughput. It is the standard choice for infrastructure monitoring, IoT sensor data, and application performance tracking.
InfluxDB is purpose-built for time-series data — it outperforms general-purpose databases (PostgreSQL, MySQL) by orders of magnitude for time-ordered inserts and range queries. If you're collecting IoT sensor readings, server metrics, application performance data, or any measurement that changes over time, InfluxDB handles millions of inserts per second and compresses the data efficiently. Version 2.x adds a built-in UI and Flux query language.
Port 8086 for both the web UI and the InfluxDB HTTP API. Keep it internal — your monitoring agents (Telegraf, apps) connect to it locally. Use a reverse proxy on 443 if you need external access to the UI.
Direct alternatives: Prometheus (pull-based, better for Kubernetes, shorter retention by default), TimescaleDB (PostgreSQL extension — SQL + time-series), VictoriaMetrics (faster, InfluxDB line protocol compatible). For IoT: InfluxDB wins. For Kubernetes monitoring: Prometheus + Thanos/Cortex. For SQL: TimescaleDB.
Don't use InfluxDB if you only need Prometheus-style scraping for Kubernetes — Prometheus is purpose-built for that ecosystem. And if you need ACID transactions or relational joins, a general-purpose database is better. InfluxDB excels specifically at high-throughput time-ordered data.
PrismaTechWork provides end-to-end infrastructure services — from initial deployment and security hardening to ongoing monitoring, automated backups, and dedicated support. Whether you need a single-server setup or a multi-site network, our team ensures your infrastructure is built right, secured properly, and maintained reliably.
InfluxDB 2.x is a complete rewrite with a built-in web UI, Flux query language (replacing InfluxQL), built-in Telegraf configuration, and unified API. InfluxDB 1.x used InfluxQL (SQL-like) and had no built-in UI. Most new deployments should use 2.x.
Yes — Grafana has a native InfluxDB datasource plugin supporting both InfluxQL and Flux. For InfluxDB 2.x, use the Flux query language mode. Add the datasource in Grafana with your InfluxDB URL and a read-only API token.
Telegraf is InfluxDB's open-source collection agent with 300+ plugins for system metrics, databases, APIs, and IoT devices. You don't need it — you can write directly to InfluxDB via the HTTP API — but Telegraf makes collecting from standard sources (CPU, disk, Docker, MySQL) trivial.
Flux is a functional data scripting language designed for time-series operations. Instead of SQL's `SELECT ... GROUP BY`, Flux chains operations: `from(bucket: 'metrics') |> range(start: -1h) |> filter(fn: (r) => r._measurement == 'cpu') |> mean()`. It's more powerful for time-series math.
Set retention when creating a bucket or update it: `influx bucket update --name mybucket --retention 30d`. Data older than the retention period is automatically deleted. Create multiple buckets with different retentions (e.g., raw 7d, hourly 365d).
High cardinality means having tags with many unique values (e.g., a `user_id` tag with millions of unique users). InfluxDB indexes all tag values, so high-cardinality tags create massive indexes that slow writes and queries. Store high-cardinality values as fields, not tags.
Yes — InfluxDB is designed for high write throughput. A single node can handle hundreds of thousands to millions of points per second depending on hardware. The TSM storage engine batches and compresses writes for efficiency.
Run `docker compose pull && docker compose up -d`. Always back up data before upgrading. For minor versions (2.x → 2.y), upgrades are usually seamless. Check the InfluxDB changelog for any breaking changes in Flux behavior or API.