pitch.database.do
The data persists. The database disappears.
The data primitive of the estate: state that outlives every request, typed once and shared across every runtime — behind a front door that serves today, with every gate to the rest stated in the open.
↓ scroll · arrow keys
An application is a thin, replaceable film over its data — the state is the part that must survive. Yet the default offer to a builder holding a schema is still the machinery around it: an instance to size, a cluster to tend, replicas to place, migrations to choreograph, backups to rotate, connection pools to tune, and a scaling event to answer at three in the morning. The serverless wave called that bluff halfway — a real class of stores now sells persistence with no instance to size — and stopped at the wall of the single database: each store its own silo, its types redeclared from scratch, its records meaning nothing to the sibling store or the agent that did not write them. The schema took an hour; keeping it alive, or making it mean anything one database over, is apparently still a profession.
The tax lands hardest exactly where the estate's whole premise lives: on builders and businesses too small to carry a database practice. A primitive you must operate is not a primitive. If state is the durable layer of the machine economy — what functions read, workflows checkpoint, and agents remember — then persistence has to be sold at the unit of state, or the layer that stays longest keeps costing the most to keep.
Three things in this estate are the substrate itself: the studio, the platform, and the runtime. This is deliberately not a fourth. database.do is the data primitive the platform operates — the durable unit of the infrastructure estate, wearing its own door because the builder who arrives holding state is a different ICP from the business with an infrastructure decision, and a brand here is one ICP and one motion.
It completes the runtime trio the platform composes: functions.do executes the unit of work, workflows.do orchestrates it, and this door persists what it produces — the layer the other two are stateless without. In the estate's own registry the coordinate is exact: noun Database, verb store, type primitive — filed at priority P1, status planned, a filing this record reports at face value on the bindings slide rather than editing the books from a deck.
// the intended contract — stated as design, not as a live warranty
const db = await database('crm') // a database, held by name
await db.contacts.create({ name, stage }) // typed by shared semantic types
await db.contacts.find({ stage: 'evaluating' }) // answered where the caller runs
There is nothing else to author. The design — stated here as intent with its public gate below, not as a live self-serve promise: the declared schema is the whole artifact, its types semantic and shared across databases rather than redeclared per store, while the substrate carries what a database practice used to — replication, migrations, backups, placement. The live front door itself positions further reach — multi-database operations, cross-database queries, distributed transactions — and this record treats that as the door's stated ambition, posting each piece as capability only when the self-serve loop below can demonstrate it.
The public self-serve loop — sign up, declare a schema, read your first persisted record — is not yet the thing this record can post. The live page headlines a global query-latency figure; this record does not adopt it, or any performance or consistency figure, until benchmarks publish with their method and window. Capability claims post behind this gate.
Concreteness over adjectives: each door below was checked cold on 2026-07-30 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 tenancy, metered billing in production, or a usage roll. Those publish behind their own gates.
database.do serves. The front door a builder would resolve is live and
sells this layer in its own words — a unified data platform: shared
semantic types, cross-database queries, global reach. (It currently wears
the plural "Databases.do" wordmark — a naming seam this record states
openly on the bindings slide rather than smoothing over.)
The gateway routes this primitive as a named service today: GET https://apis.do/database returns a machine-readable JSON record — no
login, no signup — naming the service, its domain database.do, its
description "Serverless Database", its category infrastructure, and its
status available.
platform.do serves — the operator's front door, whose own record files
this primitive among its composed runtimes under the same claim
discipline.
functions.do serves — the execution sibling: the compute whose results
this layer exists to persist.
workflows.do serves — the orchestration sibling: the runtime whose
checkpoints are state held here.
agents.do serves — the runtime whose agents are the machine readers and
writers this primitive is built to answer.
The ambers, worn in the open — each the exact distance between what serves and what this door intends to be. Two of them run the unusual direction: the estate's own books lag its live door.
The domain's own machine door answers in structured JSON today — and has
nothing behind it: database.do/api returns a well-formed envelope with
NOT_FOUND, the very address the gateway's service record points to as
this service's API. A machine that resolves this primitive finds a door
that speaks its language and is not yet open. The claim flips when the
catalog serves at that address.
The estate's role table files this domain as the runtime.database
binding of the constitution's runtime — with status pending, while
the sibling runtime.workers binding at agents.do is already active. The
estate does not round up its own registry: the binding is declared here
at its filed state, and this claim flips when the registry does.
The domain registry still files database.do at status planned, priority P1 — filed before the door lit, and 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.
The live apex serves a page titled "Databases.do" — the plural — selling multi-database operations, while the estate's registry files database.do (the data primitive) and databases.do (multi-database management) as separate coordinates. One name, two filings, one live page: reconcile the filing or re-point the surface. Queued for the decision queue; non-blocking, because the green claim above asserts only that the door serves, which stays curl-true either way.
Primary motion is B2D: the buyer is a developer who evaluates in the
docs and converts at the first persisted read — 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 the deck's most
important amber. Secondary is B2A: state, once it lives here, is what
an agent reads and writes through the gateway — and the first step of
that motion already serves, because the gateway returns this service's
machine-readable record, status available, to a caller with no login.
Purchase and settlement for the machine motion gate on the contract
surface, exactly as the sibling records state for theirs.
Layer-1 economics at the durable grain: fixed cost is the shared substrate — placement, replication, the operations practice run once for everyone; each additional database is a namespace on it, so blended margin improves with density while the metered model follows the bytes held and the operations served.
Persistence is the one primitive whose marginal cost is honest by nature: bytes held are bytes paid for, which is exactly why the metered model fits it — the substrate's operations practice is a fixed cost amortized across every tenant, and the variable cost tracks the state itself. What the builder stops paying for is the part that never belonged to their schema: the standing machinery and the practice of tending it. And there is no regulatory floor anywhere in this function: nothing in persisting a record reserves a step for a statutory person, so the implementation mix migrates all the way to Code.
Metered on state — storage held and operations served — is the intended model, and the rate card IS the pricing surface: it binds when it posts at the contract surface — verbs, protocol, rate card, guarantees — not before, and never as prose in a deck. No figure is published or implied until then.
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.
every brand the estate launches keeps its records on the estate stack this primitive anchors — demand generated by the portfolio’s own search process, structural before commercial; the usage roll publishes behind its stack#1 §A5 gate or not at all
the estate’s gateway already routes /database 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
moving compute is a redeploy; moving data is a migration project — a structural pull this record declines to dress up as lock-in: the tenancy this layer earns is the integration around the records, and it holds only as long as the contract stays worth staying for
functions, workflows, and data are composed runtimes under one operator and, when it posts, one contract — unbundling the primitive re-creates the integration burden the builder came here to delete
Serving is a liveness fact, not a tenancy claim: each posted URL below evidences that one door resolves — not that anyone occupies it.
database.do serves — the primitive's front door is live.
apis.do/database serves machine-readable JSON — the gateway's service
record for this primitive resolves for a machine with no login, status
available.
platform.do serves — the operator of the composed runtimes is live.
functions.do serves — the execution sibling is live.
workflows.do serves — the orchestration sibling is live.
agents.do serves — the sibling runtime is live.
The domain's own machine door — a structured envelope with nothing behind it today — is the next gate, and the most important one for the B2A leg: state an agent cannot read is a promise, and this deck declines to make it in present tense.
The estate's runtime.database binding remains filed pending, and this
record reports its registry at face value until the registry flips.
The domain registry's own filing — planned, P1 — lags the live door; the record wears the lag rather than editing the books from a deck.
The apex wears the plural identity; the registry files two coordinates. Queued for reconciliation, stated here in the open.
The public self-serve loop and every performance and consistency figure gate together — benchmarks publish with their method and window, or not at all.
No figure is published or implied until the card posts where it binds.
The front door is database.do — it serves today.
If this was forwarded to you: database.do is the data primitive of the startups.studio estate's infrastructure layer — the durable unit that completes the runtime trio the platform composes: functions execute, workflows orchestrate, database persists. It is deliberately not one of the estate's three substrate properties, and its deck says so; it is the primitive under them, sold to the builder who has state and refuses to hire a database practice to keep it alive. What is live is posted with a URL checked cold; what is not is pending with the gate that flips it — including the ambers it wears openly: the machine catalog, the estate's own registry filings that still lag this live door, the naming seam at its own apex, and the self-serve path with its benchmarks. Judge it by what is posted, and by how plainly it labels what is not.