How Long a New HyperCrux Engine in C Would Take: Four to Six Weeks, Phase by Phase

The Beta plan describes a new database engine for HyperCrux, written in C, with all four handles built in. A plan like that needs a time estimate before anyone decides whether to start it. Here it is: about 19 to 30 working days of development to reach the Beta gate, which comes to roughly four to six weeks of calendar time with a working session most days. A first working version with all four handles would come in about a week.

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.

Phase by Phase

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

Storage is the biggest phase because it’s where data loss would come from, so it gets the hardest tests, from a power cut at every single write to processes killed at random moments. The first working version takes shortcuts there. It would let one process use a file at a time and keep AltSql’s two syncs per commit. Its search code would only run on x86 processors. That’s useful for trying the design and well short of the Beta’s bar.

What the Estimate Rests On

Two projects from this month set the pace. HyperCrux 0.1, about 5,400 lines of Go and tests, went from the go-ahead to a published release in about a day, an independent review and the fixes it asked for included. AltSql DB, the C storage the Beta would build on, was made the same way: it grew from 0.1 to 0.3 between October 2 and October 5, about 11,300 lines of C counting its tests and tools, with a power cut tested at every write and a long fuzzing run behind it.

The Beta comes to roughly 30,000 new lines with its tests, close to three times AltSql DB, and its hardest parts are harder than anything in either project. That’s where the range comes from. The low end assumes the hard parts go the way they did before. The high end leaves room for them not to.

What Could Make It Longer

Phase 1 is the main risk. The plan asks for one sync per commit and for readers in other processes that never wait for the writer, and both have to survive AltSql’s crash tests. If those tests keep finding problems, the phase could double. Two syncs per commit stay as the fallback, so the later phases don’t have to wait for it.

A few other things would move the number:

• Growing AltSql’s own SQL instead of using SQLite’s query engine adds one to two weeks, for joins and a planner that understands them.
• Starting without AltSql’s storage adds one to two weeks, plus building the crash testing AltSql already has.
• Windows is the likeliest surprise, because growing a memory-mapped file is awkward there.
• Long fuzzing and crash-test runs take hours of machine time each, though most of it overlaps with other work.
• Claude only remembers what’s written down in the repository between sessions, so every session starts with some reading. The phases are sized to fit a few sessions each.

What Time Can’t Buy

Reaching the Beta gate means passing every test in the plan. Being trusted with real data is a different thing. SQLite earned that over years of use, and no development speed shortens it.

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.