DEV Community: Wes E

I built a native DuckDB IDE in Rust, and the client is DuckDB too

Wes E — Wed, 30 Sep 2026 15:24:23 +0000

Most SQL GUIs treat DuckDB as one more driver on a list. You get the SQL every
database shares, and DuckDB's best parts — FROM-first queries, DESCRIBE, table
functions, its own types and admin functions — come second.

I wanted a client that only speaks DuckDB, so I built one. DuckPlus is a free,
MIT-licensed Mac app written in Rust on gpui, the UI framework Zed is built with.
This post covers the parts that were interesting to build.

The client is DuckDB too

DuckDB now has its own client/server protocol, Quack. A server takes one line:

CALL quack_serve('quack:localhost', token := 'super_secret');

DuckPlus embeds an in-memory DuckDB whose only job is to speak Quack. When you
press Cmd+Enter, this is what goes over the wire:

SELECT * FROM quack_query(
  'quack:db.internal:9494',
  '<your sql>',
  token := '...'
);

The server's own parser handles your statement, DDL and multi-statement scripts
included. Results come back in DuckDB's vector format, not through a generic
driver. I use quack_query instead of ATTACH 'quack:...' because attaching still
has catalog gaps.

Local .duckdb files are opened by the same embedded engine, so a file and a
server behave the same way in the app.

Three more choices keep the UI responsive:

Schema lookups run on their own connection, so the tree never waits behind a long query.
Every query runs on a fresh clone of the connection, so a cancelled one can't block the next.
Each new query window gets its own connections to the same server.

A cell becomes text only when it's on screen

Results stay as the Arrow batches DuckDB returned. The grid is virtualized: it
builds only the rows you can see, and formats only the cells in them. Rows you
never scroll to are never turned into strings.

The grid stops pulling batches at 10,000 rows by default, and the status bar
tells you when it hits the limit. Sorting knows what it has: if every row is
loaded it sorts in place, and if not, it asks the server again with ORDER BY.

Editing without surprises

You can double-click a cell and type. Edits are staged until Cmd+S, and then
they all go in one transaction. The hard part is making sure an UPDATE changes
exactly the row you meant. So every UPDATE is paired with a check:

BEGIN TRANSACTION;
SELECT CASE WHEN count(*) <> 1
  THEN error('Expected 1 row where "id" = ...') END
FROM "analytics"."main"."users" WHERE "id" = '10437';
UPDATE "analytics"."main"."users"
SET "plan" = 'team', "mrr" = '49'
WHERE "id" = '10437';
COMMIT;

If the key isn't really unique, or someone deleted the row in the meantime, the
check raises an error inside the transaction and nothing is saved.

Rows are found by the primary key, then a UNIQUE constraint, then a column you
pick. DuckLake tables declare no keys, so there you pick one. A plain
SELECT ... FROM one_table is editable; joins, GROUP BY and CTEs make the result
read-only.

Small guardrails

DROP, DELETE and TRUNCATE need a second Cmd+Enter. The check matches whole words, so a column called dropped_at doesn't trigger it.
Every saved connection has a colour, shown in the title bar. Red means production.
Tokens go to the macOS Keychain, not to a file.

Admin screens are just queries

The sidebar has seven server views: databases, storage, extensions, settings,
memory, secrets and running Quack servers. Clicking one puts its SQL in the
editor and runs it. For example, Extensions is:

SELECT extension_name, loaded, installed, extension_version, install_mode, description
FROM duckdb_extensions()
ORDER BY loaded DESC, installed DESC, extension_name;

You can see it, change it and keep it.

What it doesn't do (yet)

Quack is beta until DuckDB 2.0 and has no remote cancel. Cmd+. frees the window, but the server finishes the statement.
It's DuckDB only, on purpose.
It's Mac only for now (macOS 12+, Apple silicon and Intel). gpui runs on Windows and Linux, but the installer and bundle don't yet.

Try it

Download: https://duckhouse.co/duckplus
Source: https://github.com/wes/duckplus

If you want a hosted server to point it at, every DuckHouse database is a Quack
server. That's what I work on day to day. But DuckPlus works with any
quack_serve, including one on your laptop.

Issues and PRs are welcome. I'd especially like to hear from people using
DuckLake or very large local files.

Your contract templates should live in your repo, not in a WYSIWYG editor

Wes E — Wed, 19 Aug 2026 17:09:19 +0000

Every time I've needed signatures inside a product I was building, the same thing
happened. The signature part took an afternoon. The contract part took weeks —
because the legal text lived in someone else's WYSIWYG editor, behind a login,
with no version history anybody on my team could review.

That's a strange place to keep the one document with legal consequences.

So the tool I ended up building keeps templates as Markdown files. Here is the
whole format:

---
title: "Freelance Agreement"
description: "Flexible agreement for freelance work and projects."
category: Services
---

# FREELANCE AGREEMENT

**Effective Date:** {{effective_date}}

This Freelance Agreement is entered into by:

**Freelancer:**
{{freelancer_name}}
{{freelancer_address}}
{{freelancer_email}}

## 1. PROJECT DESCRIPTION

{{project_description}}

Frontmatter, headings, {{variables}}. That's it. There is no other syntax to
learn, because there is no other syntax.

Why this shape matters more than it sounds like it should

A Markdown template is a file. Files do things that editor content can't:

It diffs. When someone changes the indemnity clause, that change shows up in
a pull request as a red line and a green line. A non-engineer can read that diff
and tell you what changed. Try getting that out of a rich-text editor's revision
history.

It reviews. The contract your company sends is now subject to the same
approval process as the code your company ships. Same reviewers, same audit
trail, same blame. If your legal counsel wants to own the clause language, they
own a file — and git log says when they last touched it.

It tests. You can lint it. You can grep every template for a term you're
retiring. You can write a test that fails if a template loses a required
variable. I have all of these; none of them were possible when the source of
truth was a form field on someone else's server.

It's yours. The template is in your repo whether or not you keep using my
product. That's a deliberate property, not an accident — I've been on the wrong
end of an export button before.

The full flow, end to end

Four calls. Auth is an x-api-key header on all of them; the base is
https://apisign.io/api.

1. Push a template. content is the Markdown above, verbatim:

curl -X POST https://apisign.io/api/template/create \
  -H "x-api-key: $APISIGN_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Freelance Agreement",
    "content": "# FREELANCE AGREEMENT\n\n**Effective Date:** {{effective_date}}\n..."
  }'

Returns { "template": { "id": "...", ... } }. Every save writes a version row,
so the server keeps its own history alongside your git history.

The natural next step is a CI job: on merge to main, POST each changed
.md file. Your templates are then deployed the same way your code is.

2. Create a contract by filling the variables in:

curl -X POST https://apisign.io/api/contract/create \
  -H "x-api-key: $APISIGN_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Freelance Agreement — Jane Doe",
    "template_id": "TEMPLATE_ID",
    "variables": {
      "effective_date": "2026-08-10",
      "freelancer_name": "Jane Doe",
      "freelancer_email": "jane@example.com",
      "project_description": "Design system refresh, 6 weeks."
    },
    "expires_in_days": 14,
    "signers": [
      { "email": "jane@example.com", "name": "Jane Doe", "signing_order": 1 }
    ]
  }'

You get back the contract and its signers. Each signer carries an explicit
signing_order, so sequential signing is a number rather than a workflow
builder. The signing link itself is generated at send time and goes into the
email — it is not on the create response.

3. Send it:

curl -X POST https://apisign.io/api/contract/send \
  -H "x-api-key: $APISIGN_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "contract_id": "CONTRACT_ID" }'

Signers get an email with their link. They sign in the browser — no account, no
app, no download.

4. Find out when they signed. Register a webhook endpoint and you'll get
contract_signed when a signer finishes and contract_completed when everyone
has. (Yes, underscores. Stripe and GitHub use dots and I'd probably pick dots if
I were starting today, but renaming them is a migration with a live integration
on the other end, not a Tuesday.)

One thing I'd tell you to do anyway: reconcile against GET /contract/get
rather than trusting delivery. Webhooks retry with backoff, but the retry is
kicked by your org's next event rather than by a scheduler, so a failed delivery
to a quiet account waits. Every attempt is visible via the webhook API. I'd
rather you know that than discover it.

What it costs, since that's the next question

$0.25 per contract sent. No subscription, no per-seat charge, no minimum. A
contract with six signers costs the same as one with one signer, because the
charge is per send, not per signature. A resend goes through the same path, so it
costs another $0.25 — there's no free reminder, and I'd rather say that here than
have you find it on the invoice.

Where it falls short

Nobody outside my own companies has paid for this yet. That's the honest number
and I'd rather lead with it than build a logo wall.

Some specifics, because "early" is a word people use to avoid a list:

API key read / read_write permissions aren't enforced yet. The setting is stored and displayed; nothing checks it. Treat every key as read-write and don't hand one to a third party expecting it to be scoped.
There's no rate limiting on the API.
No idempotency key on send. If your HTTP client retries a timed-out send, you can be charged twice and your signer gets two emails. Guard the call on your side.
Webhook retries are best-effort, per above.

There are 37 templates in the library to start from, and an MCP server if you
want an agent driving it.

If you keep contract text in a WYSIWYG editor today and it's working fine for
you, this isn't worth switching for. If you've ever tried to find out who changed
a clause and when, I built this for that.

Docs: https://apisign.io/docs — happy to answer anything here, including the
parts that don't work.