Blog

Your Telegraf + Grafana + Alerts Stack, Now on a Database That Doesn't Buckle

Point Telegraf and Grafana at a different URL and keep the rest of your observability stack. What transfers unchanged, where InfluxQL behaviour differs, and what ships in the open-source binary.

Austin

02 Jun 2026 • 5 min read

You've built a solid observability pipeline. Telegraf collectors scraping hundreds of endpoints, Grafana dashboards visualizing every service metric, and alerting rules catching issues before users notice. Everything runs on InfluxDB 1.x—and it's working, mostly.

But there's a catch. Every time your team asks for high availability or replication across data centers, the answer comes with a price tag: InfluxDB Enterprise. The open-source database you chose is suddenly a six-figure conversation.

You don't have to rebuild anything.

The Drop-In Replacement That Keeps Your Stack Intact

HyperbyteDB is an InfluxDB v1-compatible time-series database built on embedded ClickHouse with columnar MergeTree storage. It accepts the exact same line protocol, speaks InfluxQL fluently, and exposes the same HTTP API endpoints your Telegraf agents and Grafana dashboards already hit.

The migration isn't a rewrite. It's a URL change.

What Actually Works Without Modification

Telegraf: One Line Changes

Your Telegraf configurations likely have an outputs.influxdb section pointing at your InfluxDB instance. HyperbyteDB accepts the same write endpoint—POST /write with line protocol—and supports the same query parameters (db, rp, precision). Gzip-compressed payloads work too, so your bandwidth-conscious setups transfer unchanged.

If you're using Telegraf's InfluxDB v1 output, you literally change one line:

# Before
urls = ["http://your-influxdb:8086"]

# After
urls = ["http://your-hyperbytedb:8086"]

Every input plugin—CPU, memory, disk, network, custom scripts, SNMP, Prometheus scraping—continues working. No retesting of data collection pipelines. No reconfiguration of aggregation intervals.

InfluxQL Queries

HyperbyteDB's InfluxQL support covers the full range of queries you'd run against InfluxDB 1.x:

Aggregations: mean(), median(), count(), sum(), min(), max(), percentile(), stddev(), and more
Transforms: derivative(), non_negative_derivative(), difference(), moving_average(), cumulative_sum(), elapsed()
Time grouping: GROUP BY time(5m) with offset support
Fill modes: fill(null) and fill(0) behave as in InfluxDB. fill(previous) and fill(linear) are implemented via ClickHouse INTERPOLATE, and boundary behaviour at series start and end can differ
Subqueries and regex measurements: supported, with documented exceptions — SELECT INTO with a regex source is not

Your Grafana dashboards send these exact queries, and they execute against HyperbyteDB’s ClickHouse-backed query engine. Where behaviour diverges from InfluxDB v1 there are a handful of documented cases, listed in the compatibility write-up.

Grafana Dashboards: Point, Configure, Done

Grafana talks to InfluxDB 1.x over HTTP. HyperbyteDB responds to the exact same endpoints with the same response format. Your existing data sources, dashboard variables, and annotation queries all transfer.

No datasource reconfiguration beyond the URL. No query rewrites. No panel-by-panel validation. The dashboards you spent hours building? They're ready to visualize your data on day one.

Alerting Pipelines: Same Rules, Same Behavior

Alert rules built in Grafana, Alertmanager, or any InfluxQL-based alerting system query the same /query endpoint. The evaluation logic—thresholds, durations, aggregations—executes against HyperbyteDB's query engine identically.

Your on-call rotations stay effective and your escalation paths remain intact. Validate your alerting queries against the known differences before cutting over — alerting is the one place where a marginal difference in results actually matters.

What You Gain (That InfluxDB Enterprise Charges For)

Master-Master Replication Built In

HyperbyteDB includes master-master replication in the open-source binary. Every node accepts reads and writes. Data replicates asynchronously to all peers via HTTP. Your Telegraf agents can point at any node—writes propagate to the rest.

InfluxDB charges Enterprise pricing for this. HyperbyteDB includes it by default.

High Cardinality Without the OOM

When tag cardinality explodes—and in production environments, it always does—InfluxDB 1.x starts crawling. HyperbyteDB handles high cardinality natively through its columnar storage layer and ClickHouse query engine. The same InfluxQL queries that time out on millions of series complete without a schema rewrite.

Adding Nodes

Add nodes to the cluster and update the peers list. Each node gets a unique node_id and lists the others' addresses. Clustering is active-active — every node accepts writes, with async or sync-quorum replication — and no Enterprise contract is required. Note that this is replication rather than sharding: each node holds a copy. Sharding, which splits series across nodes, lands this year.

S3-Compatible Backups

The Kubernetes operator defines one-shot or scheduled backups to S3-compatible storage with configurable retention, and handles restores by coordinating scale-down, data copy and scale-up. To be precise about scope: this is backup and restore. S3 as a primary or tiered storage backend is not supported today.

The Migration Path

Here's how teams typically migrate:

Deploy HyperbyteDB (single node or cluster) alongside your existing InfluxDB instance
Update Telegraf output URLs to point to HyperbyteDB
Verify dashboards and alerts against the new database
Point Grafana datasources to HyperbyteDB
Retire the old InfluxDB once you've validated query results match

How long this takes depends on how many dashboards and alert rules you need to validate. The mechanical part — pointing Telegraf and Grafana at a different URL — is minutes. The validation is the actual work, and it is worth doing properly.

What This Means for Your Team

You are not choosing between stability and capability, and you are not asking your team to learn a new query language or rebuild dashboards. You are pointing an existing observability stack at a database that ships replication and retention in the open-source binary rather than behind a tier.

The metrics you collect, the dashboards you built, the alerts that wake people up at 3 AM—all of it transfers. The only new thing is a database that doesn't buckle under load.

Running InfluxDB v1 and hitting its limits? HyperbyteDB takes the same line protocol and the same InfluxQL — you change a URL. It’s open source and free to self-host, or HyperbyteDB Cloud runs it for you. See pricing, or request early access.