Starting over, in public
This site used to be about coaching. From here it is about founding a company and building a database at the same time: the engineering, the commercial decisions, and the parts I get wrong.
For about a year this domain hosted a blog about sales engineering and customer success. That work was real and I stand behind every word of it. But it stopped describing my days somewhere around the point where I started writing a database instead of talking about them.
So this is a reset, and a wider one than a change of topic. I’m going to write about being a founder, not just about the code.
Two things at once
I build Arc, an open, SQL-native time-series database, and I run Basekick Labs, the company around it. Those are genuinely two jobs, and most of what I’ve learned in the last year lives in the friction between them.
Arc exists because of a pattern I watched play out for two decades from the technical side of the commercial conversation:
- A team instruments everything. Good.
- The volume grows faster than anyone modelled.
- Storage cost forces a retention policy.
- Six months later, someone needs the data that got downsampled away.
Step four is where the interesting engineering lives. Step three is where most databases quietly hand you the bill. Arc’s answer is unglamorous: ingest through InfluxDB Line Protocol so your existing agents keep working, write standard Apache Parquet to storage you already own, compact it in the background, and query recent and historical data through one SQL surface. The files are just Parquet. If Arc ever stops being the right tool, your data doesn’t need migrating.
That’s the technical half. The other half is the one I had no training for: how do you price an AGPL product without resenting the people who never pay you? When is a feature request a roadmap and when is it one loud customer? What do you say to someone evaluating you against a database with a decade’s head start and a real support org, and how do you say it honestly, when sometimes the right answer is “not us, not yet”?
What will show up here
Both halves, without pretending the technical one is the whole story.
On building the thing:
- Benchmarks with their assumptions stated. Arc ingests north of 34 million records per second in the configuration I’ll describe. That number is useless without the hardware, the batch shape, and the durability settings, so I’ll publish those alongside it.
- What broke. Compaction strategies that looked correct and weren’t. Parquet layouts that made one query fast and four queries slow.
- Migration reality. Moving off InfluxDB is mostly a data-plumbing problem,
not a database problem.
tsm2arcexists because I underestimated exactly how much of one.
On building the company:
- Open source and money. What AGPL actually buys you, what it costs you, and the conversations it starts with enterprise procurement.
- Selling to people who can read the source. My old job was helping engineers evaluate software. Now I’m on the other side of that table, and the view is different than I expected.
- Decisions I’d make differently. Including the ones that are still playing out, which are the harder ones to write about.
- Solo-founder logistics. Where the time actually goes when you are the engineer, the support team, and the person answering the pricing email.
No newsletter funnel, no course, no gated PDF. Just posts, an RSS feed, and my email.
If you’re here for a reason
If you’re evaluating time-series databases, migrating off InfluxDB, or arguing with a retention policy you don’t believe in, those are my favourite conversations. If you’re building something on your own and want to compare notes on the unglamorous parts, that’s a close second.
Arc has a Discord, the issues on GitHub are read by me, and email works too.
More soon. There’s a backlog of things I’ve learned the expensive way.