pitch.sqlite.do2026

sqlite.do

The database ships with the code.

SQLite — the engine you already chose — placed where your code actually runs. The front door and the gateway record serve today; every gate to the rest is stated in the open.

sqlite.dothe engine door of the estate’s database-integration shelf — the most widely deployed database engine there is, placed where the code actually runs, for the builder who refuses to trade a working engine choice for a network hop13 posted · 14 pending

The most-deployed database engine is in the wrong place

SQLite earned its ubiquity on one premise: the database is a library, embedded with the code — no server, no hop, no operations practice. It is in the phone in your pocket and the browser you are reading this in. Then the code moved to the edge, and the premise broke: there is no local disk that persists where edge code runs, so the builder who already has a working schema, a tested dialect, and an ORM configured for SQLite is told the answer is a different database — hosted, a network hop away, with new quirks and a new bill. That is not an engine problem. The engine was never the problem. It is a placement problem being sold as a migration.

The arrival this door serves is specific: the decision is already made. The schema exists. The tests pass against it. What the builder needs is for the choice to survive the move to the edge — the engine unchanged, the placement made the platform’s problem. An embedded database that must live across a network hop has been un-embedded; if the code went global, the engine’s own premise says the database goes with it.

One shelf, three doors — the boundary rules

This record and the sibling sql.do’s filed in the same wave — the first two of the estate’s database-integration shelf — and this one records its boundaries as rules, not vibes:

  • database.do — the data primitive: the buyer arrives holding state and no engine opinion, and buys persistence at the unit of state. Arrive holding a schema and records that must simply outlive requests → that door.
  • sql.do — the query-language door: the buyer’s noun is SQL as an interface — the dialect — engine unnamed. Its apex serves today and its record filed first in the same wave as this one, drawing its own boundaries against the persistence primitives rather than against this engine door — so the engine/dialect boundary is recorded from this side until the sibling aligns.
  • sqlite.do — the engine door: the buyer’s noun is SQLite itself and where it sits. Arrive holding a schema.sql, a .db file, an ORM set to the sqlite dialect → this door.
Posted

sql.do serves — the query-language sibling’s front door is live under its own name and canonical, checked cold 2026-07-31.

sql.do
Posted

database.do serves — the data primitive’s front door is live; its own record wears its own seams under the same claim discipline.

database.do

The rule that routes every edge case: what is the buyer unwilling to give up? State → primitive. The language → sql.do. The engine → here.

The contract is the one you already know

There is nothing to learn, because the contract is SQLite’s: the SQL you have, the dialect your ORM already speaks, tagged templates over it for the SDK grain and plain HTTP for the machine grain. The published packages document exactly this shape — and this record posts it as the documented design, never as a live self-serve promise, because the gate below has not flipped.

Pending

The public self-serve loop is not yet the thing this record can post. The live apex headlines latency, edge-footprint, and free-tier figures; this record does not adopt them — or any performance figure — until benchmarks publish with their method and window. Capability claims post behind this gate.

gate: self-serve loop live at the sqlite.do docs surface — name a database, run a query, read it back — with published latency benchmarks (method …
typescript
// the intended contract — stated as design, not as a live warranty.
// Documented in the published packages (npm: sqlite.do@0.0.1, turso.do@0.0.1):
const db = createDatabase('my-app')          // a database per name — per tenant, if you like
const users = await db.sql`SELECT * FROM users WHERE id = ${userId}`
await db.transaction(async (tx) => {         // ACID, single-writer
  await tx.sql`INSERT INTO accounts (name) VALUES (${'Acme'})`
})
bash
# the same database over plain HTTP, per the published REST contract:
POST /api/{database}/query
{ "sql": "SELECT * FROM users WHERE active = ?", "params": [true] }

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

sqlite.do serves. The front door a builder would resolve is live under its own name and canonical, selling exactly this layer — SQLite at the edge with type-safe access. (The page wears a stylized “SQLiTE.do” wordmark casing — a small templated-generation seam this record notes rather than smooths.)

sqlite.do
Posted

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

apis.do/sqlite
Posted

The implementation has public artifacts: the sqlite.do package is published on the public npm registry at version 0.0.1 — “high-level API and utilities for distributed SQLite on Cloudflare” — with a README documenting the HTTP query contract shown on the contract slide. Version 0.0.1 means what it says: pre-1.0, and this record says so.

registry.npmjs.org/sqlite.do
Posted

The managed-service client is likewise published and public — npm package turso.do, version 0.0.1, “managed service client for Turso-compatible SQLite on Cloudflare.” Its name is the seam the next slide wears openly.

registry.npmjs.org/turso.do
Posted

platform.do serves — the operator’s front door, whose own record files the estate’s composed runtimes under the same claim discipline.

platform.do

The seams, stated honestly

The ambers, worn in the open — each the exact distance between what serves and what this door intends to be.

Pending

The domain’s own machine door does not yet speak machine: the gateway’s service record points to sqlite.do/api as this service’s API, but that path answers with the gateway’s HTML front page — even to a caller asking for JSON — and sqlite.do/llms.txt answers 500. An agent that resolves this engine today should use the gateway record, which serves; the domain’s own catalog posts behind this gate.

gate: sqlite.do/api answers a machine caller with this service's JSON record
Pending

The estate’s own registry still files sqlite.do at status planned, priority P1 — filed before the door lit, not yet updated to match the live surface. 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: sqlite.do status flips planned → implemented
Pending

The engine work lives in a repository that is private today — a cold fetch of it 404s — so nothing in this record cites repository contents. The public artifacts are the published packages at 0.0.1, and the contract slide draws only on their public READMEs. The deeper architecture posts when the repo or a docs surface does.

gate: the implementation repository public, or its architecture published at a docs surface this record can cite
Pending

A naming seam runs through the shelf: the implementation’s managed-service client is published on npm as turso.do, while the estate’s registry files turso.do as a separate vendor-flavored coordinate — whose apex does not serve today. Resolve one way: re-key the package under this door’s name, or light the turso.do coordinate and file the boundary. Queued for the decision queue; non-blocking, because every green claim above asserts only what its own evidence URL serves.

gate: package naming reconciled — the flagship client is published as `turso.do` while the registry files turso.do as a separate coordinate
Pending

The rest of the shelf is dark: postgres.do, redis.do, turso.do, and neon.do each answered 500, checked cold 2026-07-31 — and none of the registry’s other database-integration coordinates answered either; of its fourteen rows, only this door and sql.do serve. This record states that as a dated fact and declines to dress it as an advantage — the shelf is designed to light door by door, and this claim flips as it does.

gate: the neighboring engine doors serve — postgres.do, redis.do, turso.do, neon.do

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 package README and the docs and converts at the first query answered next to the code — no sales motion, no demo call, no procurement. The evaluation surface is the product surface, which is why the self-serve gate on the contract slide is this deck’s most important amber. Secondary is B2A: the first step already serves — the gateway returns this service’s machine-readable record, status available, to a caller with no login — and a per-name database reachable over plain HTTP is a natural unit for an agent to hold state in. But the machine motion is claimed exactly as far as it serves: the domain’s own machine door still answers in HTML, and that gate is worn on the seams slide, not hidden under a roadmap adjective.

The economics of the engine door

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

Layer-1 economics at the integration grain: the placement machinery — per-name placement, single-writer consistency, durable archival — is a fixed substrate run once for everyone; each additional database is a name on it, so blended margin improves with density while the metered model follows state held and queries served.

The engine is free and public domain — that is precisely the point, and this record does not pretend to sell it. What is sold is placement: the machinery that keeps an embedded database embedded when there is no disk, run as shared substrate. Marginal cost is honest by nature — bytes held and queries served — which is exactly why the metered model fits. And there is no regulatory floor anywhere in this function: nothing in placing a database reserves a step for a statutory person, so the implementation mix migrates all the way to Code.

Pending

Metered on state held and queries served is the intended model; the registry files the coordinate at tier free and the apex headlines a free starting tier — but the rate card IS the pricing surface and it binds when it posts at the contract surface, not before, and never as prose in a deck. No figure is published or implied until then.

gate: rate card posts at the capability contract surface
Pending

Database counts, storage volumes, query volumes, 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 engine door holds

The install base is the funnelthe ICP arrives already trained: SQLite’s schema, dialect, tooling, and ORM ecosystem are the onboarding — the door’s designed property is that there is nothing to learn and nothing to abandon, and the record sells that property on its own terms rather than as a comparison
Gateway positionthe estate’s gateway already routes /sqlite 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
Per-name grain, worn honestlya database per name makes tenant isolation the default unit rather than a schema trick — and the record declines to dress data gravity as lock-in: tenancy holds only as long as the contract stays worth staying for
One seam with the platformthe engine door is one door of the estate’s composed stack — the same substrate that runs the portfolio’s own state — so its demand is structural before it is commercial, and unbundling it re-creates the placement problem the builder came to delete

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

sqlite.do serves — the engine door’s front page is live under its own name and canonical.

sqlite.do
Posted

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

apis.do/sqlite
Posted

The sqlite.do package is public on npm at 0.0.1, README documenting the HTTP contract this deck shows — pre-1.0, stated as such.

registry.npmjs.org/sqlite.do
Posted

The turso.do client package is public on npm at 0.0.1 — the naming seam it carries is worn openly on the seams slide.

registry.npmjs.org/turso.do
Posted

sql.do serves — the query-language sibling this record draws its boundary against is live.

sql.do
Posted

database.do serves — the data primitive neighboring this shelf is live under its own record’s discipline.

database.do

Pending — the gates that flip it

Pending

The domain’s own machine door — the gateway record names it, and it answers in HTML today. The most important gate for the B2A leg: state an agent cannot read is a promise, and this deck declines to make it in present tense.

gate: sqlite.do/api answers a machine caller with this service's JSON record
Pending

The public self-serve loop and every performance figure gate together — benchmarks publish with their method and window, or not at all.

gate: self-serve loop live at the sqlite.do docs surface — with published latency benchmarks (method and window)
Pending

The registry’s own filing — planned, P1 — lags the live door; the record wears the lag rather than editing the books from a deck.

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

The repo is private today; the published packages are the public artifacts, and nothing here cites what a stranger cannot resolve.

gate: the implementation repository public, or its architecture published at a docs surface this record can cite
Pending

The flagship client’s name and the registry’s coordinate disagree; queued for reconciliation, stated here in the open.

gate: package naming reconciled — `turso.do` the package vs turso.do the registry coordinate
Pending

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

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

The ask

The front door is sqlite.do — it serves today, and the gateway answers for it by name.

If this was forwarded to you: sqlite.do is the engine door of the startups.studio estate’s database-integration shelf — SQLite, the most widely deployed database engine there is, placed where edge code actually runs, sold to the builder whose engine choice is already made. It is deliberately not the estate’s data primitive (that is database.do) and not the query-language door (that is sql.do); the boundary rules are recorded inside. What is live is posted with a URL checked cold — the front door, the gateway’s machine record, the published packages — and what is not is pending with the gate that flips it, including the ambers it wears openly: the machine door that still answers in HTML, the registry filing that lags the live door, the private repository, the package-naming seam, and the dark sibling doors on its own shelf. Judge it by what is posted, and by how plainly it labels what is not.

13 posted · 14 pending