Custom work across the DuckDB platform we build.
Extensions, VGI workers, and hardened Haybarn distributions — the same things this site documents, built against your systems instead of the public catalog. We'll tell you which one you need, including when that's a worker built in a week rather than a native extension.
What we have shipped so far
These figures come from the same data the extension catalog is built from, and they update when it does. Each one links to its source so you can check it.
Which layer your problem is in
A DuckDB problem usually sits at one of four layers, and which layer it is decides what gets built, how long it takes, and what it costs. The left column is the platform as it already exists — extensions, Haybarn, VGI, and Rowfence all have their own pages if you want the detail. The right column is the work we do there.
Establishes which of the four below you are actually in, and whether a worker would do the job more cheaply than an extension. Credited against the build.
Haybarn or DuckDB
The engine your team already runs
Pin an extension set, sign the build, write the upgrade policy, hand over the review packet.
DuckDB extensions
32 published · loaded in-process
For the cases that genuinely need C++ — custom types, storage, or optimizer work.
Rowfence
Preview
Which rows and columns a caller sees
An entitlement model, row filters, and column rules built against your real access rules.
VGI workers
Your APIs, services, databases, and models
The cheaper answer for most connectors — no C++, no build matrix, and no per-release rebuilds.
Teams often arrive certain they need the extension row and leave having bought the engine row, or the other way round. That is what the review at the top is for.
Three tracks, and a review that sorts you into one
Most connectors are built as VGI workers now, not native extensions — no C++, no platform build matrix, no rebuild every time DuckDB releases. We reserve native extension work for what a worker genuinely can't reach: custom types, storage, or optimizer changes. Coding agents can write a solid first draft of either kind for the common case; we review what they produce and do the parts that still need a person.
Feasibility review
You know what you need to query. You do not yet know whether that is a worker built in a week, a native extension, or something nobody should build.
- We check the catalog and the community repository first
- A written recommendation: VGI worker, native extension, or neither
- A proof-of-concept that returns real rows from your real source
- An estimate you can take to whoever holds the budget
A VGI worker
The default path for a connector now. No C++, no build matrix, no rebuild every time DuckDB releases.
- Python, Go, Rust, Java, or TypeScript — your choice
- A coding agent writes a first draft for the common case; we review it and finish it
- Auth, pushdown, and caching handled by the protocol, not hand-rolled
- A template your team reuses for the next one without us
A native extension
For the cases a worker cannot reach: custom types, storage, or a change to the query optimizer.
- Written in C++, in-process, where that is the only option
- Full platform build matrix — including a WebAssembly build we run, not just compile
- Published to the community channel, or kept private
- Your repo, your licence, your CI
Production readiness
You have it working and now it has to survive a security review, an upgrade, and a person leaving.
- A pinned, signed Haybarn distribution with build provenance
- An upgrade policy that survives the next DuckDB release
- A security-review packet: checksums, signatures, attestations, and what is deliberately not in the catalog
- Runbooks that outlive the engagement
Anything that isn't one of these three — code review, pairing with your team on an agent-assisted build, or open-ended advisory — is billed at $3,000/day. Standing relationships become a monthly retainer at the same rate, scoped to a fixed number of days.
The deliverable is working software
What you receive at the end is the same kind of artifact already in our catalog — the same repository layout, the same signing, the same generated documentation, and the same community channel if you want it published there.
You own the repository and choose the licence. Your CI builds it. It continues to work whether or not you keep working with us.
INSTALL your_thing FROM community;
LOAD your_thing;
-- or, if it's a worker:
ATTACH 'yoursystem://prod' AS yoursystem (TYPE vgi);Two examples in the open
Client work is mostly under NDA, so here are two pieces of infrastructure work we did on the DuckDB ecosystem itself. Both write-ups include the methodology and the raw numbers.
We rebuilt the community extension catalogue and made it 2.4× faster
Every DuckDB release invalidates every community extension binary until it is rebuilt, which is why upgrades break INSTALL. We measured the whole pipeline and rebuilt it around a read-write vcpkg cache: 104 CI-hours against a modelled 245, on identical runners.
Read the analysis →We tested every WebAssembly extension and found a third of them broken
A WASM extension that compiles has proven it compiles — not that it loads, and not that it runs. We built a harness and ran all 124 WASM-enabled community extensions against the published engine. The failures had green badges the whole time.
Read the teardown →What the weeks look like
We check the catalog
If an existing extension already reads your source, we tell you and the engagement stops there.
A failing test
The first commit is a test against your real source, so you can confirm we understood the problem before we build on it.
Build, in your repository
You review pull requests as they land. We do not run a separate status meeting unless you want one.
Handover
Your engineers make the last commits and run the build themselves, so the work does not depend on us afterwards.
The tools underneath the work
Most client work is built on one of these three, configured for a specific system. All three are open source and documented, and they are used by plenty of people who have never contacted us.
VGI
The protocol behind worker builds — Arrow over pipes, sockets, or HTTP, in five languages. Most connector work happens here now.
Extensions
32 published extensions. When a build genuinely needs C++, this is the shape it takes.
Haybarn
Signed builds and provenance. The production-readiness track is Haybarn, configured for your constraints.
Questions we actually get
What if an extension already exists for our source?
Then we'll say so on the call and you'll have saved yourself an engagement. It happens more often than you'd think — there are 32 in our catalog and several hundred more in DuckDB's community repository.
Do we have to replace our warehouse?
No, and we'd usually rather you didn't. Most of what we build sits beside what you already have: DuckDB reads the Parquet your warehouse already writes, or a worker fronts a system the warehouse was never going to reach. “Rip out Snowflake” is not a project we're interested in selling you.
Who owns the code?
You do. The repo is yours, the licence is your choice, and the build runs without us. If it's genuinely reusable we may ask whether you'd like it published as a community extension — which means we keep it building on every DuckDB release, for free. That's an offer, not a condition.
What happens when a new DuckDB version breaks our extension?
This is the real question and most people ask it too late. Every community extension is a separate binary that has to be rebuilt for each engine release, so shipping is not the end of the work. Fixed-price builds include rebuilds for six months; after that it is a support retainer, or we hand you the CI that does it and you take it in-house.
How do you price?
Fixed, wherever the scope is knowable — which covers most worker and extension builds. Anything open-ended — advisory, pairing, code review — is $3,000 a day. We don't run time-and-materials on a build we scoped ourselves; if we estimated it wrong, that's our problem.
Are you going to have an AI write our extension?
Where it helps, yes. Coding agents can write a solid first draft of a VGI worker, and increasingly a DuckDB extension, for the common case. We use them, review everything they produce line by line, and take over by hand for the parts that still need a person — a novel type system, storage internals, or anything where a subtle mistake is expensive. You're paying for that judgment, not pretending the agent isn't there.
What do you not take on?
Warehouse migrations, platform strategy engagements, staff augmentation, and anything that needs a 24/7 on-call rota. We will tell you on the first call rather than the fourth.
Tell us what you're trying to query
Thirty minutes, no preparation. Describe the system, who needs to query it, and what you've already tried — we'll tell you which part you actually need, including "none of them, do this instead."
- ✓ We'll say if one of the 32 extensions already does it
- ✓ We'll say if a worker is the cheaper answer, and it usually is
- ✓ No sales sequence, no drip campaign
We reply within two working days. No newsletter unless you ask.