How Co-locating Code and Data Boosts App Performance by 450%

Modern web apps often spread their layers across separate processes—Node.js here, MongoDB there—connected by slow network calls. Each round-trip adds serialization delays, TCP stack latency, and protocol overhead, even on localhost. Planck flips that model by embedding both the database engine and application runtime inside one process, turning database queries into instant in-memory function calls.

The Zero-Distance Advantage

Planck merges the storage layer (built on a WiscKey-style LSM tree) with a WebAssembly runtime, eliminating network hops entirely. Instead of routing requests through TCP sockets or Unix domain sockets, your application code executes directly within the database process. This co-location reduces latency to near-zero, cutting the overhead that typically slows down every database interaction.

Tools to Build and Run

Deploying a Zero-Distance app requires three core components:

• Planck: The unified binary that hosts the database and runs your WebAssembly application. It loads compiled WASM modules directly into its memory space, merging storage and logic.

• planctl: A command-line utility for compiling, packaging, and deploying your code. It also manages database operations like creating stores, defining indexes, and handling backups or exports from the terminal.

• Workbench: A built-in web console for monitoring performance, managing schemas, running queries, and scheduling tasks such as garbage collection or export jobs.

Setting Up Planck Locally

Getting started is straightforward. First, download the Planck release for your OS from the official repository, then extract it to a local directory.

mkdir -p ~/.planck
tar -xzf planck-0.3.0-macos-arm64.tar.gz -C ~/.planck --strip-components=1

Next, add the Planck binaries to your shell path. Edit your shell configuration file (e.g., ~/.zshrc) to include the Planck bin directory:

export PATH="$HOME/.planck/bin:$PATH"

Reload the shell (source ~/.zshrc) and confirm the binaries are available:

which planck planctl workbench

Initialize the system once to set up services and directories. On macOS this registers background agents via launchd, while Linux uses systemd:

sudo planctl system init

Access the Workbench dashboard at using the default admin credentials (admin and a provided key). Save the connection profile to ~/.planctl/config.yaml` to streamline future deployments.

Coding in WebAssembly: Zig vs. Node.js

A frequent concern is that WebAssembly forces developers into low-level languages like Zig. In practice, writing handlers with the Schnell framework feels similar to building Express routes. Both approaches handle routing, request parsing, and response formatting.

Here’s a side-by-side example of a simple category endpoint:

// Node.js with Express
app.get('/categories', async (req, res) => {
  const categories = await db.collection('categories').find().toArray();
  res.send(renderCategories(categories));
});

// Zig with Schnell
pub fn handle(ctx: ?*anyopaque, allocator: Allocator, req: *const Request, res: *Response) !void {
  const categories = try db.listCategories(allocator);
  const html_fragment = try renderCategories(allocator, categories);
  try res.html(html_fragment);
}

The Schnell framework abstracts routing and request handling, while planctl automates the WebAssembly compilation pipeline. Developers write idiomatic Zig code without wrestling with manual WASM bindings or build scripts.

Benchmark Results: Planck vs. Traditional Stack

To compare performance, the Planck team built planck-pizzahub, a self-contained benchmark that duplicates a pizza-ordering service in two stacks:

• planck-pizzahub: A Zig application running as a WebAssembly module inside Planck.
• express-pizzahub: A Node.js/Express app connected to a local MongoDB instance.

Both versions use the same 17 categories and 201 products, serving identical HTML fragments formatted for the Datastar framework.

Running the Node.js stack requires MongoDB and a few setup commands:

cd perf-compare/express-pizzahub
npm install
npm run seed
npm start

The Planck version uses a single command to compile and deploy:

cd perf-compare/planck-pizzahub
planctl deploy

Early tests show Planck delivers up to 4.5 times faster response times under load, thanks to zero network overhead and in-process execution. While results vary by workload, the pattern holds: removing inter-process communication removes delays.

The Path Forward

Planck’s Zero-Distance Architecture redefines how applications interact with data. By collapsing the storage and logic layers into a single process, it unlocks measurable performance gains without sacrificing developer experience. Teams exploring high-throughput or latency-sensitive systems should evaluate whether Planck’s model aligns with their architecture goals.

As WebAssembly matures and database engines evolve, co-location could become a standard pattern—not just an optimization. The tools and benchmarks available today make it easier than ever to test this shift and measure its impact firsthand.