Arc's New Release Cadence: From Monthly to Quarterly

Since Arc went public in October 2025, we've shipped a major release every month. Nine of them, on the dot, from November through June. Each one carried real features: Azure support, native TLS, MessagePack columnar ingestion, peer-to-peer replication, the Helm chart, Enterprise GA, and a long list of performance and correctness work in between.

That cadence did its job. It signaled velocity to a market tired of waiting six months between InfluxDB releases. It forced operational discipline on a small engineering team. And it gave us something to write about every four weeks while we were catching up to the rest of the category.

We're not catching up anymore.

Today we're announcing that Arc is moving to a quarterly major release cadence, starting after 26.06.1 ships at the beginning of June. The next major releases land in September 2026, January 2027, and April 2027. Patch releases (26.06.2, 26.06.3, etc.) ship as needed for critical fixes, usually within 7 to 14 days of a customer-reported issue.

Here's the reasoning, what changes, and what does not.

The Real Reason: Production Teams Shouldn't Run on a Feature Treadmill

When Arc Enterprise customers deploy in production, they don't want a major upgrade landing in their ops queue every 30 days. They want to know two things:

When is the next major upgrade window? So they can plan validation, testing, and deployment.
If I skip a release, am I behind? Because real production systems never adopt every release the day it ships.

Monthly cadence answers question 1 with "next month, every month, forever." That sounds great until you're the team responsible for promoting a database upgrade through dev, staging, UAT, and production. Then it sounds like an endless treadmill.

Quarterly cadence answers question 1 with "September, then January, then April." Predictable. Plannable. Skippable when the workload calls for it.

And question 2 gets answered cleanly: if you skip a major release, the patches you actually need are still flowing on the version you're running. Critical fixes don't wait for the next major. They ship as 26.06.2, 26.06.3, 26.09.2, whatever it takes. The major release cycle is for features, not for fixes.

This is the cadence pattern PostgreSQL, ClickHouse, and MongoDB have converged on. It's not slowness. It's the cadence production teams want from infrastructure they're going to bet on.

The Other Reason: Arc Reached Feature Parity

When we look at what InfluxDB, TimescaleDB, QuestDB, ClickHouse, and the other competitors offer for time-series and observability workloads, Arc covers it: ingestion at multiple millions of records per second, native Parquet on S3/Azure/local, DuckDB SQL, four data types unified under one protocol, retention policies, continuous queries, schema evolution, MQTT, bulk import, Telegraf, Red Panda Connect, Helm-based clustering, replication, RBAC, tiered storage. The list of "table stakes for a TSDB in 2026" is checked.

There are still features we want to ship: a web-based query UI for Arc OSS (Arc Cloud already has one), more connectors, deeper Enterprise observability tooling, things production customers will surface as they run Arc at scale. Those continue. But they don't justify shipping every 30 days the way catching up did. We covered that pivot in Arc's repositioning post earlier this year.

What Changes

The headline number: four major releases per year instead of twelve.

26.06.1: early June 2026 (the last monthly release)
26.09.1: September 2026
27.01.1: January 2027
27.04.1: April 2027

Each major release will be substantial. Quarterly windows give us time to ship features that genuinely deserve a release post: performance work, new capabilities, customer-driven improvements, and the kind of cross-cutting changes that benefit from a longer baking period.

That's it. That's the whole change.

What Does Not Change

This is the part that matters most.

Patches ship whenever they need to. If a customer hits a correctness bug, a CVE drops, or a production issue surfaces, that fix ships within days, not quarters. Patch versions are the safety valve. The quarterly cadence is for features, not for fixes.

The blog stays at 2 to 3 posts per week. Migration guides, performance studies, vertical case studies, customer stories, technical deep-dives, ecosystem announcements: none of that is tied to release cycles. The content rhythm that drives inbound stays exactly where it is.

The repository stays alive. GitHub commits, issue triage, pull-request reviews, experiments, performance tuning, and incremental improvements continue at the same pace they have for nine months. If anything, the freed bandwidth means more time to engage on community PRs and contributor work.

Customer commitments don't slow down. Enterprise customers get the same response times, the same SLA, the same direct access. Fewer release cycles means more time for the work that actually moves their projects forward.

The OSS edition stays AGPL-3.0 and stays serious. Quarterly cadence is not a precursor to commercial-only features creeping into the core. The Enterprise tier stays what it has always been: production-grade clustering, replication, advanced operational features. The OSS edition is and will remain a complete, capable, professional time-series database.

What This Signals About Arc

A monthly cadence in months one through nine signaled "we're catching up, building fast." A quarterly cadence in month ten and beyond signals "we're a real product now, one operators and engineering teams can plan around."

The shift is from a pace that says wait, this is coming to a pace that says this is here, deploy it.

If you're running Arc in production today, nothing about your operational reality changes: same patches, same support, same database that has been serving you well. If you're evaluating Arc for the first time, you're looking at a system that has stopped racing and started maturing, exactly the timing most teams want from infrastructure they're going to bet on.

The next major release lands in September. In the meantime, the blog keeps rolling, the patches keep flowing, and the conversations with customers keep deepening.

Get started:

Questions? Discord or https://github.com/Basekick-Labs/arc/issues.

Analytical Database

Streaming

AI Memory

Forum

Source & Issues

Real-time chat