Document store
LSM-shaped: skiplist memtable, WAL append, value log, B+tree primary index, secondary indexes. BSON documents, u128 keys.
.wasm. Inside the database.Planck is a document database with a WASM runtime built in. Your handlers query the store through a typed builder, in the same process, no socket, no ORM. Deploy is one binary uploaded with one command.
Storage engine, WASM runtime, HTTP server, change streams, replication, plus a workbench control plane that drives backups, GC, and the rest. Nothing to glue.
LSM-shaped: skiplist memtable, WAL append, value log, B+tree primary index, secondary indexes. BSON documents, u128 keys.
Your service compiles to one .wasm. Planck loads it next to the store. Reads and writes are function calls, not network round-trips.
Method-chain: store.filter(...).orderBy(...).limit(N). Range scans, aggregates, projections, get-by-key. No ORM.
Render HTML fragments for HTMX / Alpine / Datastar, return JSON for an API, or stream bytes. The same handler decides per route.
Subscribe to store mutations from inside a service or over the wire. Watch a single key, a range, or a whole store. Filterable, observable.
Primary ships WAL frames to a read-only replica asynchronously. Rotated WAL segments can also stream to an archive path for offsite retention.
Cron-style tasks for backup, GC, WAL truncate, stats snapshot, export, import. Per-app or per-service. Editable from the workbench.
An optional SSE service subscribes to change streams and fans events out to browser EventSource clients. Hypermedia front-ends update without polling.
Browser control plane on :2369. Deploy, run PQL, edit schedules, view logs, manage backups, watch the store. Everything operations cares about.
The database, the HTTP server, the WASM runtime, the template engine, and your handlers, all in the same process.
Same primitives, three architecture styles. Planck supports all three.
One planck instance per bounded context: orders, products, billing. Each owns its data, its handlers, its UI fragments. Cross-context work via change streams or direct calls.
One planck instance, one .wasm, handlers across every domain. The classic monolith: compiled, sandboxed, deployed in one step. Stores share an instance but stay independent at the schema level.
Same pattern as A, but handlers return JSON instead of HTML fragments. Everything still runs as WASM inside planck. The only difference is the wire format your clients consume.
A and B are both Self-Contained Systems: many vertical slices versus one. C is the classic API-services style, where the UI lives outside the service boundary. Planck supports all three from the same primitives.
A complete operational surface (engine, control plane, CLI) plus the libraries you build services against.
The database engine. Storage, WAL durability, change streams, replication, WASM runtime. Ships as a single binary.
Web control plane on :2369. Auth, supervision, deploy receiver, scheduler, query workspace, backup orchestration.
The CLI. Scaffold projects, build the WASM, deploy or undeploy, backup, restore, manage system lifecycle.
Talk to the store from native code over TCP or from WASM via host calls. Typed builder, change streams, schema decode.
HTTP server + framework for WASM handlers. Routing, middleware, sessions, streaming responses, schema validation.
Optional SSE service. Subscribes to change streams, fans events out to browser EventSource clients per topic.