
HyperbyteDB
A sharded time-series database, built so tag cardinality stops being a ceiling.
Speaks InfluxDB v1 line protocol and InfluxQL, so switching costs you one URL. Open source.
A time-series database without a cardinality ceiling
The problem is tags, not volume
Time-series databases rarely fall over because of how many points you write. They fall over because of how many distinct series those points create. Add a container ID, a device serial, a player session, and the series count multiplies — a database comfortable at a hundred thousand series starts taking seconds to answer queries that took milliseconds.
InfluxDB v1 was built for lower-cardinality workloads, and it is very good at them. The problem is that nothing about your business stays low-cardinality, and the exits are all bad: drop the tags you needed, downsample data you'll want next quarter, or move up to a tier where replication stops being optional.
Change one URL
Your monitoring, IoT, observability or analytics stack already speaks InfluxDB v1 line protocol and InfluxQL. HyperbyteDB is a full drop-in replacement:
- Same `/write` and `/query` endpoints
- Same InfluxQL you know (aggregates, derivatives, moving averages, GROUP BY time(), subqueries, regex measurements, and more)
- Same clients and agents (Telegraf, Grafana, etc.)
- Continuous Queries
- High Availability Replication
Point them at HyperbyteDB and go. The documentation covers the endpoints in detail.
The numbers, and where they came from
| Sustained ingest | ~1.5M points/sec at p95 under 250ms |
| Peak ingest | ~1.9M points/sec |
| Measured on | AMD EPYC 7413, 24c/48t, 251GB RAM, single node |
| Engine component ceiling | ~99M rows/sec |
We lead with the sustained figure because it is the one that survives a capacity plan. The 99M is real too — it is the storage engine with nothing in front of it. Between the two sit a network, a parser, a series index and a durable write-ahead log, and that gap is where the honest number lives.
Where the other 98% goes · How the engine reaches 99M · Reproduce it yourself
Sharding
HyperbyteDB runs today as a single node, and a single node has a cardinality limit however good the storage engine is. Sharding splits series across nodes — that is what turns cardinality from a hard limit into a capacity decision. It lands this year, and when it does we will publish the same kind of measurement we published for ingest.
What changes for you
Tag what you actually want to tag. Columnar storage and a ClickHouse execution engine handle wide WHERE clauses and high-cardinality tags without the series explosion that degrades InfluxDB v1.
Replication without a sales call. Master-master clustering where every node accepts writes, in the open-source binary rather than behind a licence tier.
Durable by default. Writes land in a RocksDB write-ahead log before acknowledgement, then flush to columnar storage in the background.
No rewrite. The migration is a URL change, not a project.
Self-hosted or managed
| Self-hosted | Cloud | |
| Licence | Open source, on GitHub | Early access |
| InfluxDB v1 compatibility | Full | Full |
| Replication & HA | Yours to run | Managed |
| Upgrades, backups, restore tests | Yours to run | Managed |
| Price | Free | Pricing |
HyperbyteDB Cloud runs it for you. Early access is open to a small number of design partners.
Solutions







