influxdb

InfluxDB v1 Compatibility in HyperbyteDB: What Works, What Doesn't, and How to Cut Over

HyperbyteDB speaks InfluxDB v1 line protocol and InfluxQL on the same endpoints. The precise version: endpoint coverage, InfluxQL support, the known differences, benchmark numbers and what to watch when cutting over.

Austin

• 5 min read

Our strongest signal for product-market fit is not a benchmark or a feature list. It is that teams drop HyperbyteDB in by changing one URL in an existing Telegraf config.

The usual migration story goes: export this, transform that, rewrite your writers, hope. This post is the precise version of the shorter story — what works out of the box, what diverges, and what to watch on the way across.

The compatibility surface

HyperbyteDB exposes the InfluxDB v1 HTTP API on port 8086. The endpoints match what existing tooling expects:

  • POST /write — ingest line protocol, supports precision and gzip
  • GET/POST /query — execute InfluxQL, supports epoch and multiple statements
  • GET /ping and GET /health — liveness and health checks
  • GET /metrics — Prometheus scrape endpoint on the same port

Your Telegraf output config, your Grafana datasource and your custom scripts need no rewrites. Point them at your HyperbyteDB host instead of your InfluxDB host:

# Before (telegraf.conf)
urls = ["http://influxdb-host:8086"]

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

Run CREATE DATABASE mydb via the v1 /query endpoint, then point your writers at it. Measurements, tags and fields behave as you expect.

Line protocol

Standard InfluxDB line protocol is accepted verbatim:

cpu,host=server1,region=us-east value=42 1700000000000000000
sensor,device=foo temp_c=23.5,humidity=65.1

Precision suffixes work as documented. Nanosecond precision is supported, and second or millisecond precision transfers directly.

InfluxQL coverage

  • DDL: CREATE DATABASE, CREATE USER, SHOW USERS, retention policy management
  • Aggregates: mean, count, sum, percentile, derivative, non_negative_derivative, moving_average and more
  • Time grouping: GROUP BY time(), FILL modes, ORDER BY, LIMIT
  • SHOW commands: SHOW MEASUREMENTS, SHOW TAG KEYS, SHOW TAG VALUES, SHOW SERIES
  • Continuous queries: CREATE CONTINUOUS QUERY, DROP CONTINUOUS QUERY

Grafana's InfluxQL query builder generally works without modification.

What we validated

  • Telegraf — the standard InfluxDB output plugin works unmodified. Batch sizes, write intervals and timestamps transfer directly.
  • Custom HTTP writers — anything that POSTs line protocol to /write?db=<name> works. Tested with Python requests, Go net/http and bash curl.
  • Grafana — datasources pointing at InfluxDB v1 switch over by changing the URL.

The storage layer is different — ClickHouse MergeTree tables, not TSM files — but the wire protocol is the surface area, and we kept it identical.

Known differences

Compatibility is broad. The storage engine is architecturally different, so some behaviour diverges:

  • Storage format. ClickHouse MergeTree tables rather than TSM shards. TSM compaction and retention policies map onto MergeTree partitioning and ClickHouse TTLs. Retention policies are honoured on reads; data lands in columnar files rather than TSM segments.
  • fill(previous) and fill(linear). Implemented via ClickHouse's INTERPOLATE clause. Boundary behaviour at series start and end may differ from InfluxDB's exact semantics. For strict compatibility, prefer fill(null) or fill(none).
  • SELECT INTO with regex. Regex source matching (SELECT * INTO :MEASUREMENT FROM /^cpu/) is not supported. List explicit measurement names.
  • Permissions model. Admin and non-admin roles, but no per-database GRANT/REVOKE. If you need database-level access control, plan accordingly.
  • Floating-point edge cases. ClickHouse's floating-point handling at boundaries can produce marginally different results. For critical alerting or billing, validate against your previous results during migration.
  • Existing data. We do not migrate TSM files directly — you export from InfluxDB and import. See exporting historical time-series.

Ingestion benchmark numbers

Criterion measurements on Linux x86_64 (April 2026), 1000-point batches. Reference points, not guarantees.

BenchmarkThroughputWhat it measures
parse_1000~1.84M points/sLine protocol parsing only, no I/O
parse_plus_metadata_1000~1.56M points/sParse + RocksDB metadata preparation
metadata_plus_wal_append_1000~1.05M points/sParse + metadata + WAL append
metadata_plus_wal_append_1000 (columnar)~2.0M points/sMessagePack path: parse + metadata + WAL
fast_metadata_plus_wal_append_1000~2.6M points/sFast metadata path + WAL

These exclude HTTP server overhead, authentication, replication and query processing — they are the library layer only, measured with Criterion on temp directories. A synthetic benchmark measures one dimension; a running system with dashboards, continuous queries and cluster replication does not. Treat them as a ceiling.

For the end-to-end number that survives a capacity plan, see what an ingest benchmark does not tell you.

What to watch when cutting over

  • Batch sizing. Similar to InfluxDB OSS, but if you are coming from a heavily tuned Enterprise setup your sweet spot may differ. Start with your current size and tune.
  • Query patterns. Test your specific queries against the known differences above. Most teams find the compatibility surface covers their workloads; the ones that hit edge cases usually find a workaround the same afternoon.
  • Alerting and billing queries. Validate these against previous results before cutting over. They are the ones where a marginal difference matters.

Try it yourself

docker pull ghcr.io/hyperbyte-cloud/hyperbytedb:latest

docker run -d \
  --name hyperbytedb \
  -p 8086:8086 \
  -v hyperbytedb-data:/var/lib/hyperbytedb \
  ghcr.io/hyperbyte-cloud/hyperbytedb:latest

curl -sSf http://localhost:8086/health

Then point Telegraf or your own writer at http://localhost:8086. To run the ingestion benchmarks locally:

# Line protocol path
cargo bench -p hyperbytedb --bench ingestion_line_protocol

# Columnar path (MessagePack)
cargo bench -p hyperbytedb --bench ingestion_columnar

Reproducible benchmarks are part of the product. You should be able to validate a claim rather than take it on faith.

The short version

HyperbyteDB is not a rewrite of InfluxDB. It is a different engine that speaks the same protocol: line protocol in, ClickHouse MergeTree underneath, RocksDB WAL for durability, the same HTTP API on the way out. If your tooling speaks InfluxDB v1, the only configuration change may be the URL.

The InfluxDB v1 Migration Checklist: Which Clients Just Need a URL Change
Most migration posts focus on one client. The reality is InfluxDB v1 stacks have Telegraf, Grafana, custom apps, and scripts. Here's the client-by-client migration checklist that tells you which integrations just need a URL change and which need adjustment.
Hyperbyte CloudAustin
Your Old Data Isn't a Migration Blocker: Exporting Historical Time-Series from InfluxDB v1 to HyperbyteDB
Most migration guides cover updating Telegraf, Grafana, and your scripts. But historical data—months or years of it—gets left behind with no clear path forward. Here's how to export that data from InfluxDB v1 and load it into HyperbyteDB.
Hyperbyte CloudAustin
Before you trust our numbers, run this.
Benchmark numbers mean nothing without context. Here's how to run HyperbyteDB's own ingestion benchmarks, what each stage actually measures, and the environment metadata you need before comparing anything.
Hyperbyte CloudAustin

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.