Building a database is a trust challenge.
A developer can try a new library in an afternoon. Moving a production workload to a new database takes more. Teams need to understand what happens to their data during a restart, how queries behave under pressure, what an upgrade requires, and who will help when something goes wrong.
On October 7, 2025, we made Arc's first commit. Today, Arc turns one.
What started as an open-source experiment is now an infrastructure product with customers and a community helping us make it better. People are choosing Arc for workloads that matter to them. That brings a responsibility we feel much more clearly than we did a year ago.
I'm proud of what we've built. I'm also more aware of what earning that trust takes.
Infrastructure adoption moves at the speed of trust
In our first-month checkpoint, we were asking whether there was an appetite for a time-series database built around DuckDB, Arrow, and open Parquet storage. We had early deployments, proof-of-concept conversations, and a lot to learn.
Getting someone to download a database is one step. Getting them through an evaluation, a migration, and their first production incident is a much longer relationship.
A team evaluating Arc has an existing collector, dashboards, storage policies, security requirements, and people who will be on call for it. Performance matters, but so does fitting into that environment. They need a recovery procedure they can test and an upgrade they can plan.
This year changed the questions we ask ourselves. Alongside “how fast is this?” we now have to ask “what happens when this fails, and can the operator tell?”
Where Arc stands today
Basekick Labs is profitable, with six figures in ARR across the business. That matters because maintaining infrastructure is an ongoing commitment. Recurring revenue gives us room to support customers, fix difficult problems, and keep investing in Arc.
Our instance stickiness is above 20%, measured as daily active Arc instances divided by monthly active instances. What matters to us is recurring use: the same Arc instances keep coming back and being used over time.
As of October 2, GitHub records 15 published releases and 18 human contributors to the Arc repository. Releases represent repeated work on the database people run. Contributions mean more people are reading the code, finding assumptions we missed, and improving it.
In the October 2026 DB-Engines ranking, Arc moved ahead of Amazon Timestream, with a score of 1.34 versus 1.31. DB-Engines measures popularity; it gives us a useful signal that Arc is becoming more visible. Production confidence still has to be earned in the systems people actually operate.
Customers, contributors, people evaluating migrations, and people asking hard questions are all part of that progress. The conversations are getting deeper, and the expectations are getting higher.
What the product had to earn
The first year wasn't a straight line. We rewrote Arc from Python to Go after the prototype exposed memory and operational limits. The rewrite gave us a single binary and a stronger foundation. Then came the work of making that foundation useful in more environments.
From one fast node to a system teams can operate
Arc Enterprise brought clustered deployments, replication, and separate writer, reader, and compactor roles. Supporting both shared object storage and local disks meant working through different failure and recovery paths.
The 26.09.2 release shows how much detail sits behind the word “clustering”: which nodes can lead, which writer receives replicated data, who runs retention and compaction, and how a node recovers after losing its local disk. It also added a write-specific readiness endpoint so a load balancer can distinguish a healthy node from one that should receive writes.
Those details determine whether an operator can understand the system during an incident. We had bugs in those paths, and fixing them was part of this year's work.
From ingestion endpoints to existing workflows
MessagePack columnar ingestion and InfluxDB Line Protocol gave Arc ways to receive data. Telegraf, MQTT, the Python SDK, and Grafana made it easier to connect Arc to tools people already use.
Every integration reduces something a team would otherwise have to build and maintain. Migration tooling matters for the same reason: people need a practical way to move the data they already have. tsm2arc reads InfluxDB's TSM and WAL files directly, so a team can migrate historical data without a running InfluxDB instance. A database becomes easier to adopt when the surrounding pipeline makes sense too.
From SQL access to clearer boundaries
Enterprise RBAC and query governance added controls over who can access data and how much work a query can consume. Security reports pushed us to examine those boundaries more carefully.
Result handling needed the same care. A response that stops early must tell the caller it is incomplete. A restore that skips files must report a failure. A process that cannot flush its buffers must preserve recovery data and make the failure visible.
That work is less photogenic than a benchmark chart. It is central to trusting a database.
From an engine to a daily operating experience
arcli gives operators named connections, SQL queries, imports, and administration from the terminal. Launchpad brings querying, logs, monitoring, and management into a self-hosted browser interface.
Documentation and public demos help people get from an interesting repository to an evaluation they can carry out. The Enterprise product also needs deployment guidance, upgrade instructions, and support. All of that belongs to the product people experience.
What building Arc taught me
Performance gets a conversation started. Reliability keeps it going. Benchmarks helped people discover Arc. Once a team starts evaluating it seriously, the questions become more specific: recovery, storage behavior, access controls, and how to run it over time. We have to answer those questions with working software and clear documentation.
Helping people migrate and operate Arc is an ongoing engineering commitment. One of the biggest challenges this year has been creating the tooling to move data from other platforms, then keeping that tooling efficient and working well. The same applies to Launchpad, arcli, the Grafana data source, and the Python SDK. Shipping the first version is only the beginning. We have to maintain those tools as Arc and the systems around it evolve. If importing data is painful or everyday management is awkward, the engine's performance can only take someone so far.
Failure signals must be honest. One of the hardest examples in 26.09.2 was a shutdown path that could purge the write-ahead log before every buffer had flushed. During a storage outage, a clean shutdown could lose acknowledged data. We corrected the order, retained the WAL when flushing failed, and made that failure produce a non-zero exit. We also documented the crash-recovery replay behavior, including where duplicates can occur. Trust requires explaining the behavior and its limits.
Documentation is engineering work. That release required a coordinated restart for Enterprise clusters and explicit migration steps for installations using the bundled object store. A correct implementation still needs instructions that let an operator deploy it safely. Writing those instructions forces us to examine the assumptions behind the change.
Predictable operations matter. We moved major releases to a quarterly cadence, while continuing to ship patches as needed. Teams need time to validate upgrades and choose a deployment window. Supporting that rhythm is part of supporting the customer.
Open source starts relationships. An issue, a migration question, or a contribution can teach us something long before there is a commercial conversation.
Sustainability gives us room to think beyond the next release. A profitable company lets us spend time on recovery paths, compatibility, and operational details whose value may only become obvious months later. Those are decisions I want us to keep making.
Building infrastructure from Costa Rica
We're building Arc from Costa Rica, as part of Latin America's engineering community, for people working around the world.
Our work includes storage, query execution, replication, security, and the operational tools around them. The conversations cross borders because the problems do too: a factory collecting sensor data, a team investigating logs, or engineers keeping years of telemetry available for analysis.
I want more of that engineering journey to be visible. I'm planning to start recording YouTube sessions soon: demos, tutorials, architecture, and the engineering behind Arc. I'd like to show how we make technical decisions, what breaks, what we learn from users, and how we improve it. The blog will continue to be part of that conversation too.
The people behind the first year
Thank you to everyone who contributed code, reported a bug, tested a release, asked a difficult question, or trusted us enough to start an evaluation.
Some contributions changed the way Arc handles data. Adam Schroder's work on data-time partitioning helped historical backfills land in the partitions where they belonged. Other contributions improved pruning, SQL handling, replication, recovery, and the tools around the engine.
Security reports and critical feedback also made Arc better. The latest release's acknowledgments recognize people who reproduced difficult failures and helped us fix them. That work deserves as much recognition as a new feature.
Thank you to our customers for sharing their requirements and making the product's responsibilities concrete. And thank you to the people answering questions in public. A useful answer can help many more people than the person who first asked.
What comes next
The main engineering priority for year two is ArcX, our own query engine. We're building it to replace DuckDB in Arc, with execution refined and optimized specifically for time-series workloads. The goal is to take Arc's query performance to a new level by shaping the engine around the data and query patterns Arc is built to serve.
ArcX will be proprietary. Building our own engine gives us more control over how Arc executes time-series queries. That work carries the same responsibility as everything else in this post: faster execution needs to come with correct results and behavior operators can understand under pressure.
Alongside ArcX, we'll continue to:
- Keep improving clustering, recovery, and operational visibility.
- Expand Enterprise workflows in arcli and Launchpad so operators can do more through the tools they already use.
- Make agents useful for resource analysis, diagnostics, and logs, with findings operators can inspect.
- Improve integrations and demos around real workloads.
- Share more of the engineering journey through YouTube and the blog.
The priority is to make Arc easier to understand, evaluate, and operate as more people depend on it.
Come build the next year with us
There are several ways to get involved:
- Download Arc and run it on your own infrastructure.
- Try a live demo.
- Star Arc, report an issue, or contribute on GitHub.
- Join Discord and tell us what you're building.
- Talk to Basekick Labs about Arc Enterprise if you're evaluating a production deployment.
A year ago, we wanted to find out whether people needed Arc. Today, we have people depending on it and a clearer understanding of what we owe them.
Thank you for the first year. We intend to keep earning your trust.