pitch.sql.do2026

sql.do

The dialect persists. The server disappears.

The query surface of the estate’s data layer: SQL itself, served where the caller runs — a lit front door, a public engine, and every distance between the two stated in the open.

sql.dothe query-surface of the estate’s data layer — SQL itself, sold as infrastructure to the builder whose dialect is a sunk asset, not a legacy to be migrated off12 posted · 15 pending

Every road to the edge taxes the dialect

SQL is the most portable interface the industry has ever produced — fifty years old, declared legacy by every platform shift, and still the language the schema is actually written in. Yet every current road to the edge taxes it. Keep the dialect on a managed regional database and you lose locality: every query pays the round-trip, and at serverless scale the connection-pool practice you deleted comes back as a product you buy. Keep locality on an edge-native store and you lose the dialect: the schema gets re-declared into a vendor’s typed API, and twenty years of queries become a migration project. The SQLite-at-the-edge class finally kept both — and fragmented the rest, selling branching, change capture, and analytics egress as separate products with separate bills. The builder’s most durable asset — fluency in the one data language that outlived everything — is the asset every option prices as a liability.

The estate’s data layer refuses that trade from the other side too: its record store, database.do, sells persistence to builders happy to adopt a typed surface with no SQL in it. This door exists because a second, distinct buyer arrives at the same layer holding something different — the language itself — and a brand here is one ICP and one motion.

Two doors, one layer — the boundary is what the buyer holds

The infrastructure pack sells the data layer by grain: database.do the record, state.do the position, storage.do the bytes. This door adds the dialect — and the boundaries are rules, not vibes. If the thing the buyer refuses to give up is the data — records that must persist and any good interface will do — they belong at database.do, which sells a declared schema and a typed surface with no SQL in it. If it is the language — SQL as a sunk asset in schemas, queries, tooling, and habit, engine unnamed — they belong here. If it is the engine itself — SQLite and where it sits — they belong at sqlite.do, the engine sibling on the same shelf, whose record files this same three-way rule from its side. Same direction of travel underneath; doors keyed by what walks in holding what.

In the estate’s own registry the coordinate is exact: category integrations, subcategory databases, noun SQL, verb query — filed at priority P1, tier free, status planned, a filing this record reports at face value on the bindings slide rather than editing the books from a deck. It is the belt’s first record to file by timestamp — the engine sibling sqlite.do filed seconds later in the same authoring wave — and the remaining sibling rows wait on their own doors.

The integration artifact is the query you already have

There is no new query language to learn — that is the entire point of the door. The design, stated as the dot-do/sql monorepo documents it and not one claim further: DoSQL is a SQL engine that lives inside the compute unit — a Durable Object with SQLite-class storage hot and object storage cold — rather than across a network hop from it; DoLake tails every change into an open Parquet/Iceberg lakehouse so analytics reads never touch the hot path; the repo’s own stability table marks core query execution, CRUD, and transactions stable, and marks time travel, branching, CDC streaming, and virtual tables experimental. This record keeps the repo’s labels on and promotes nothing past them.

Pending

The quickstart is not runnable cold today, and this deck says so rather than simulating it: the README’s npm install sql.do names a package the registry does not serve, and the npm name dosql is currently held by an unrelated third-party package. Until the packages publish under names the project holds, the repo is the product surface and the quickstart is design.

gate: the repo's packages published on npm under their documented names (sql.do, dosql, dolake) — or the quickstart re-pointed at names the …
Pending

Developer Preview is the repo’s own label — v0.1.0, “Not recommended for production use without thorough testing”, “Expected GA: Q3 2026“, the README’s words verbatim — and this record keeps it on. The apex headlines a global latency figure and an edge-location count; this record adopts neither, nor any performance or consistency figure, until benchmarks publish with their method and window. Capability claims post behind this gate.

gate: stable release posted per the repo's own milestone criteria, with benchmarks published with method and window
typescript
// as the public repo documents it — Developer Preview, not yet installable cold
import { createSQLClient } from 'sql.do'          // npm publication: gated below

const client = createSQLClient({ url, token })
const users = await client.query(
  'SELECT * FROM users WHERE active = ?', [true]  // the dialect, unchanged
)
await client.transaction(async (tx) => { /* ACID, savepoints */ })

What serves today

Concreteness over adjectives: each door below was checked cold on 2026-07-31 and carries its own state and its own evidence URL — never one URL evidencing several domains. Serving is a liveness fact, not a tenancy claim: nothing here asserts external tenants, production workloads, or a usage roll. Those publish behind their own gates.

Posted

sql.do serves. The front door a builder would resolve is live under its own wordmark — the hero renders “Type-Safe Sql at the Edge”, quoted verbatim with its own casing — selling exactly this door’s thesis: the dialect with types, agent access, no server to run. (Its headline latency and location figures are not adopted here; they gate on published benchmarks.)

sql.do
Posted

The gateway routes this door as a named service today: GET https://apis.do/sql returns a machine-readable JSON record — no login, no signup — naming the service sql, its domain sql.do, its category infrastructure, and its status available.

apis.do/sql
Posted

The engineering is public: the dot-do/sql monorepo serves — DoSQL, DoLake, and the sql.do client SDK, with the Developer Preview label, the stability tables, and the roadmap this record quotes — readable cold by anyone this deck reaches.

github.com/dot-do/sql
Posted

docs.platform.do serves — the target of the apex’s primary “View Docs” call to action resolves. It is the platform’s shared documentation surface, not a per-door one; the distinction is stated here, not smoothed over.

docs.platform.do
Posted

database.do serves — the companion record-grain door is live, wearing its own openly-stated seams in its own record. The boundary rule between the two doors is filed here and, from its own side, in the engine sibling’s record; the companion’s record predates this filing and carries no sql.do line yet — sibling alignment queued, stated candidly rather than assumed.

database.do
Posted

sqlite.do serves — the engine sibling on the same integrations shelf is live, and its record files the three-way boundary rule (state → the primitive, language → here, engine → there) from its side.

sqlite.do

The bindings, stated honestly

The ambers, worn in the open — each the exact distance between what serves and what this door intends to be. One runs the estate’s usual direction (the books lag the door); the machine doors run the other way (the door advertises more than a cold GET finds).

Pending

The gateway’s service record names sql.do/api as this door’s own API — and today that path serves the sibling gateway’s marketing page, not a machine door: a caller gets APIs.do’s human homepage where the record promised sql’s catalog. A machine that follows the estate’s own pointer lands on the wrong surface. Queued as a root-surface seam; the claim flips when the catalog serves at the address the record names.

gate: sql.do/api serves this service's machine catalog
Pending

The machine index is dark: sql.do/llms.txt answers 500. For a door whose second motion is agents, the index that would tell an agent what this surface is does not yet exist, and this record declines to paraphrase one into being.

gate: sql.do/llms.txt serves the door's machine index
Pending

The estate’s domain registry still files sql.do at status planned, priority P1 — filed before the apex lit, not yet updated to match it. The record reports the books at face value in both directions: the door is posted above with its evidence, and the filing is reported here as it stands until the registry flips.

gate: domains registry registry.tsv: sql.do status flips planned → implemented
Pending

The companion coupling is direction, not wiring: nothing in either door’s public surface yet documents a path by which records held at database.do answer SQL through this one. The two records file the same boundary rule; the joint mechanics post when they exist, and not as prose before that.

gate: a documented path between this door and database.do ships — records held at the companion queryable through this surface

How it goes to market

B2Abusiness serves an agent — the machine is the customeralso
B2Dthe developer reads the catalog like API docs — key funnel on the railprimary
A2Aagent to agent — pure machine commerce
B2A2Ba business system calls the rail on its own behalf
B2A2Dour agent serves the deputized developer
B2A2Cour agent serves the consumer
B2H2Aa statute names a human — the licensed supplier in the path
A2H2Athe human is a required supplier: the regulated-cell shape

Primary motion is B2D: the buyer is a developer who evaluates in the docs and the public repo and converts at the first query that round-trips — no sales motion, no demo call, no procurement. The evaluation surface is the repo today, which is why the npm gate on the contract slide is this deck’s most important amber: the moment the quickstart runs cold, the whole motion is self-serve. Secondary is B2A: the apex advertises agent access to the data, and the first step already serves — the estate’s gateway returns this door’s machine-readable record, status available, to a caller with no login. The rest of the machine motion is exactly as gated as the bindings slide says: the door’s own catalog and index are dark or mis-pointed today, and purchase and settlement for machine callers gate on the contract surface, as the sibling records state for theirs.

The economics of the dialect layer

Human~95% of function cost
Agenticorchestration-priced
Generativeinference-priced
Codenear-zero marginal

Layer-1 economics at the dialect grain: fixed cost is the engine and its operational belt — built once, in the open; each tenant database is a compute unit holding its own state, so the marginal unit tracks the tenant’s own queries and bytes while the free tier prices the first schema at zero.

A query engine that lives inside the compute unit has honest marginal economics: each tenant’s engine runs on the tenant’s own unit, storage tracks the tenant’s own bytes, and the change-capture tail lands in an open format the buyer can walk away with — the moat is not an export tax. The registry files the door free-tier and the apex says “start free”; what sits above the free tier is metered intent, and the rate card IS the pricing surface. And there is no regulatory floor anywhere in this function: nothing in parsing, executing, or persisting a query reserves a step for a statutory person, so the implementation mix migrates all the way to Code.

Pending

Freemium is the filed shape — the registry’s own tier column says free — and metered tiers above it are the intended model. The card binds when it posts at the contract surface: verbs, protocol, rates, guarantees — not before, and never as prose in a deck. No figure is published or implied until then.

gate: rate card posts at the contract surface
Pending

Tenant counts, query volumes, storage held, and the internal-versus- external split are gated. Each figure publishes with its window and base or it does not publish.

gate: StartupsStudio/stack#1 §A5

Why the dialect door compounds

The dialect is the switching cost — invertedevery other edge data product asks the builder to pay the dialect tax on the way in; this door prices arrival at zero new language, so the natural inbound is everyone whose schema already exists — a population no sibling door can address without breaking its own no-dialect promise — and the repo ships migration guides from the incumbent edge class
Engine inside the compute unita query that never crosses a network hop is a structural position, not a tuning result — the engine rides where the estate already runs its work, per the repo’s own architecture, and benchmarks publish behind their stated gate
Open-format exhaustthe change tail lands in Parquet/Iceberg — an open lakehouse, not an export tax; the tenancy this door earns is the integration around live queries, worn honestly, and it holds only as long as staying is worth it
Gateway position in the estatethe estate’s gateway already routes /sql as a named service, status available, to a machine with no login — when the reader is an agent, being discoverable and callable IS the distribution channel; the door’s own catalog gates behind the bindings slide

Where it stands

Serving is a liveness fact, not a tenancy claim: each posted URL below evidences that one door resolves — not that anyone occupies it.

Posted

sql.do serves — the front door is live under its own wordmark.

sql.do
Posted

apis.do/sql serves machine-readable JSON — the gateway’s service record for this door resolves for a machine with no login, status available.

apis.do/sql
Posted

The public monorepo serves — engine, lakehouse tail, and SDK readable cold, Developer Preview label intact.

github.com/dot-do/sql
Posted

The apex’s “View Docs” target serves — the platform’s shared docs surface, stated as shared.

docs.platform.do
Posted

The companion record-grain door serves — the boundary rule is filed from this side; the companion’s earlier record carries no sql.do line yet, and the alignment is queued, not assumed.

database.do
Posted

The engine sibling serves — same-batch filing on the integrations shelf, three-way boundary rule attested on both sides.

sqlite.do

The ambers are the roadmap

Pending

The quickstart does not run cold today — the deck’s most important amber, because the whole B2D motion converts at exactly that moment.

gate: the repo's packages published on npm under their documented names (sql.do, dosql, dolake) — or the quickstart re-pointed at names the …
Pending

The estate’s own pointer to this door’s API currently lands on the sibling gateway’s marketing page — queued as a root-surface seam, stated here in the open.

gate: sql.do/api serves this service's machine catalog
Pending

The machine index answers 500 — a door with an agent motion and no llms.txt yet, said plainly.

gate: sql.do/llms.txt serves the door's machine index
Pending

Developer Preview by the repo’s own label; every performance and consistency figure — including the apex’s headline — gates on published benchmarks.

gate: stable release posted per the repo's own milestone criteria, with benchmarks published with method and window
Pending

The registry files the door planned, P1 — the books lag the lit apex, reported at face value until they flip.

gate: domains registry registry.tsv: sql.do status flips planned → implemented
Pending

Companion coupling is direction, not wiring, until the joint mechanics post.

gate: a documented path between this door and database.do ships — records held at the companion queryable through this surface
Pending

No figure is published or implied until the card posts where it binds.

gate: rate card posts at the contract surface
pitch.sql.do2026

The ask

The front door is sql.do — it serves today, and the engineering is public at github.com/dot-do/sql.

If this was forwarded to you: sql.do is the query surface of the startups.studio estate’s data layer — the companion of database.do, keyed to a different buyer by rule: that door sells persistence to the builder who will take a typed surface with no SQL in it; this one sells the dialect itself to the builder whose SQL is a sunk asset. The engine behind it is public and labels itself Developer Preview, and this deck keeps the label on. What is live is posted with a URL checked cold — the apex, the gateway record, the repo, the docs target, the companion door; what is not is pending with the gate that flips it — the npm quickstart, the machine catalog and index, the benchmarks, the registry’s own lagging filing, the companion wiring, and the card. Judge it by what is posted, and by how plainly it labels what is not.

12 posted · 15 pending