Document store
LSM-Tree-based: Skiplist MemTable, WAL, Value Log, B+tree Primary/Secondary Indexes. BSON documents, u128 keys.
.wasm. Inside the database.Planck collapses the boundary between code and data. It is a log-structured document store with a built-in WebAssembly Runtime. Handlers query the store in-process with zero network overhead, zero serialisation and deserialisation, and no ORMs. Build, compile, and deploy your entire application with a single command.
Storage engine, WASM Runtime, HTTP Server, Change Streams, Async-Replication and a Web based Workbench control plane that can be used to monitor apps, take backups, create schemas, export/import data, schedule tasks like GC, Wal Truncate, Export/Import etc.
LSM-Tree-based: Skiplist MemTable, WAL, Value Log, B+tree Primary/Secondary Indexes. BSON documents, u128 keys.
Your service compiles to one .wasm. Planck loads it in it's own address-space. Data 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 required stores for changes.
Primary Ships WAL frames to a read-only replica asynchronously. Rotated WAL segments can also be streamed to an archive path for offsite retention.
Cron-style tasks for backup, GC, WAL truncate. 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 based control plane on :2369. Deploy, monitor stats using dashboards, run PQL, edit schedules, view logs, manage backups, watch the store. Everything operations cares about.
The database, the HTTP server, the WASM runtime and your handlers, all in the same process.
HTMX · Alpine · Datastar · JSON
HTTP listener · WASM runtime · change streams
handlers · zsx templates · query builder
memtable · WAL · vlog · B+tree · primary/secondary indexes
HTML · JSON · stream · chosen per route
Same primitives, three architecture styles. Planck supports all three.
Each domain (orders, products, billing) is a vertical slice owning its private database, business logic, and UI layout. Handlers return HTML fragments directly using HTMX or Datastar, keeping the frontend and database completely co-located.
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.
Similar horizontal slice topology to A, but handlers serve JSON data instead of UI fragments. Perfect for native mobile applications or traditional single-page apps (React, Vue) where the frontend is fully decoupled and hosted elsewhere.
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, Value Log, B+Tree, Change Streams, Replication, WAL Streaming, WASM runtime. Ships as a single binary.
Web control plane on :2369. Monitor, Schedule, Query workspace, backup, export/import, schema management.
The CLI. Scaffold projects, build the WASM, deploy or undeploy, backup, restore, schema management, export/import, 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, various third-party providers.
Optional SSE service. Subscribes to change streams, fans events out to browser EventSource clients per topic.