How Long a New HyperCrux Engine in C Would Take: About Three Weeks, Phase by Phase

The Beta plan describes a new database engine for HyperCrux, written in C, with all four handles built in around one append-only file and one copy of the data in each process’s memory. A plan like that needs a time estimate before anyone decides whether to start it. Here it is: about 13 to 19 working days of development to reach the Beta gate, which comes to roughly three weeks of calendar time with a working session most days. A first working version, with every handle except SQL, would come in four or five days.

That pace only makes sense once you know how HyperCrux is built. Claude, an AI coding agent made by Anthropic, does the development in working sessions, from the code and its tests to the docs. The project’s owner says yes or no at each gate and publishes the releases. So the estimate is counted in session days, and it rests on this project’s own record.

Working days per phase to the Beta gate, as low-to-high ranges in the order the phases run: spec half a day to one, the file three to four and marked as the largest phase and the main risk, records, keys and links two to three, vectors one to two, queries and SQL two to three, the Go package and command two and a half to three and a half, review and release one and a half to two and a half.

Phase by Phase

The phases follow the plan, and each one ends at a gate that decides whether the next one starts.

Phase	Working days
0. Spec: the file format and the C API	0.5 to 1
1. The file: batches, recovery, locking, failed writes, following other processes’ commits, compaction	3 to 4
2. Records, keys and links, in memory	2 to 3
3. Vectors and their search code	1 to 2
4. Queries and SQL	2 to 3
5. The Go package and the command, with import and export in both versions	2.5 to 3.5
6. Review, long fuzzing and crash runs, benchmarks, docs and the release	1.5 to 2.5
Total	about 13 to 19

The file is the largest phase and the main risk, because it’s where data loss would come from. Every commit and every compaction runs through it, and a crash or a failed write can hit it at any point. Queries and SQL is smaller than it would be in a bigger database, since the SQL is a subset built for one table at a time plus walks. The other phases are more predictable.

The Beta is for Linux only, on both x86 and ARM, which keeps one set of rules for syncing to disk and one operating system to test and release. macOS comes after the Beta. Most of what the code asks of the system works the same way on macOS, so that port should be small.

The first working version takes shortcuts. It keeps the file without compaction and searches with a plain C loop. SQL, the one handle it leaves out, comes later, and searches stay unfiltered until it does. It also skips the tests each gate asks for. That’s useful for trying the design and well short of the Beta’s bar.

What the Estimate Rests On

HyperCrux 0.1 sets the pace. It’s about 5,400 lines of Go and tests, and it went from the go-ahead to a published release in about a day, an independent review and the fixes it asked for included. The Beta comes to roughly 5,000 to 6,000 lines of C and as many again in tests, about twice 0.1’s size, plus a reworked Go package.

At 0.1’s pace, twice the code would take a few days. It’s harder per line, though. 0.1 leaned on SQLite for everything hard, from storage and crash safety to SQL, and the Beta builds all of that itself. Code that has to survive a crash or a failed write at any moment takes many rounds of testing and fixing before it passes, and that’s what stretches the estimate to weeks. The low end assumes those rounds go quickly. The high end leaves room for the parts that are new to this project.

What Could Make It Longer

The file is the main risk. If crash tests keep finding problems in recovery or compaction, that phase could double.

A few other things would move the number:

More SQL. Each feature past the subset, such as other joins or CASE, adds time. A first subset without grouping would take a day off.
Large databases. Every process holds the whole database in memory and reads the whole file to open it, and writers have to wait while the file is compacted, longer as the data grows. Keeping all of that reasonable near a million records may need work that isn’t counted here.
Machine time. Long fuzzing and crash-test runs take hours each, though most of it overlaps with other work.
Fresh starts. Claude only remembers what’s written down in the repository between sessions, so every session begins with some reading. The phases are sized so each fits in a week of sessions or less.

What Time Can’t Buy

Reaching the Beta gate means passing every test in the plan. Trust with real data comes later. SQLite earned it over years of use, and no development speed shortens that.

Nothing has started. HyperCrux 0.1 stays on SQLite and keeps getting fixes, and the first decision in the plan is whether to begin Phase 0. Three ways to make HyperCrux faster explains why the new engine is the largest of the options, and the download page has 0.1 today.