Warp and Weft: Weaving a Serverless SQL Database

I have spent the past few days building Twill, and the core question behind it is simple enough to state in one breath: what if a SQL database were embeddable like SQLite, yet could stand up as a real server, and scaled to zero because it is genuinely serverless? Most databases force you to choose one of those. Twill is an attempt to refuse the choice.

The false choice

The usual ladder looks like this. You start with an embedded database because it is the simplest thing that works — no process to run, no port to open, the data sits right next to your code. Then you outgrow a single machine, so you migrate to a server: a daemon you provision, patch, and pay for whether or not anyone is querying it. And if you want the modern serverless promise — scale to zero, pay only for what you use — you usually rewrite again, this time around someone else's hosted product and its constraints.

Each step is a migration, and each migration is a tax. You pay it in rewritten code, in operational surface area, and in a monthly bill that keeps running at three in the morning when nobody is awake to use the thing. The premise of Twill is that the embedded database, the server, and the scale-to-zero service do not have to be three different products you graduate between. They can be one engine wearing different clothes.

Warp and weft

The name is not decoration. In weaving, cloth is made from two sets of threads held in tension: the warp runs lengthwise on the loom, and the weft crosses it. Neither is fabric on its own. The structure — and the strength — comes from keeping them separate and then interlacing them deliberately.

Twill borrows that on purpose. The warp is compute: the query engine, the planner, the part that does the work of answering questions. The weft is storage: the durable bytes, the pages and logs that outlive any single query. The two are designed as distinct threads rather than one fused monolith, and that separation is the whole point, not an implementation detail.

When compute and storage are welded together — as they are in a classic database server — scaling one means scaling the other, and idling means paying for both. Pull them apart cleanly and each can be sized, moved, and scaled on its own terms. The weft can sit quietly and cheaply when nothing is happening; the warp can spin up the instant a query arrives and disappear again when it is done.

What the separation buys

Keeping warp and weft distinct is what makes the three promises hold at once:

• Robust. A clean seam between compute and storage is a clean failure boundary. Compute can crash, restart, or be replaced without putting the durable data at risk, because the data was never living inside the query process to begin with.
• Portable. The same engine that embeds directly in your application is the same engine that runs as a server. There is no rewrite at the boundary — you embed when you want the data next to your code, and you point at a server when you want it shared, without changing how you talk to it.
• Scale 0 → 100 without a cost burden. Because the warp is decoupled from the weft, idle truly means idle. Compute can fall all the way to zero and cost nothing while storage waits patiently, then come back up to meet real load. You pay for queries you actually run, not for a daemon keeping a seat warm.

That last point is the one I care about most. The expensive lie of "always-on" infrastructure is that it bills you for availability you are not using. A database that can honestly scale to zero turns the cost curve from a flat line into something that tracks usage — which is exactly what you want when a project is small, bursty, or just getting started.

Where this is going

Twill is early — this is a few days of building, not a finished product — but the shape is already clear, and writing it down helps me see it. The goal is a single SQL engine that meets you wherever you are on the curve: embedded when you are one machine and one process, a server when you need to share, and serverless when you want the bill to follow the work instead of leading it. Warp and weft, held apart on purpose, woven together when it counts.

More as the cloth comes off the loom.