DEV Community: Kamlesh Bambarde

Co-locating Data and Application Code for a 4.5x Performance Gain

Kamlesh Bambarde — Tue, 30 Jun 2026 03:49:15 +0000

Modern web application architectures typically run each layer in its own process, like a NodeJS server and database both running in their own processes. They communicate via a network connection or localhost socket. This separation introduces protocol overheads, TCP stack latency, and data serialization/deserialization costs on every single query.

Planck is designed around the concept of Zero-Distance Architecture that co-locates data and application code. It combines the database engine and a WebAssembly application runtime into a single, unified process. By running your application code directly inside the database process, database calls become direct in-memory function calls rather than network round-trips.

This article provides a practical guide to getting started with Planck. We will look at the core toolchain, walk through setting up a self-contained local benchmark, compare its performance against a NodeJS, ExpressJS, MongoDB stack, and look at how to build more complex features.

The Toolchain: Planck, planctl, and Workbench

Running and managing a zero-distance app requires three main components.

Planck itself is the core binary. It functions as both the storage engine (a WiscKey-style, LSM-tree-based engine) and the WebAssembly host. Instead of running a database in one process and your application server in another, you run a single Planck process. It loads your compiled WebAssembly application directly into its memory, running it in the same process space as the database.

To manage this runtime, you use planctl. This is the command-line tool for developers. It handles the compilation of your code, packages it, and deploys it to the Planck host. It also allows you to perform database operations, like creating stores and defining indexes, export/import, backup/restore directly from your terminal.

Finally, there is the Workbench. This is a web console that comes built into the platform. It provides a visual dashboard to monitor your applications, view database metrics via dashboard, manage schemas, query data and schedule tasks such as backup, import/export, Wal Truncate, Garbage Collect etc.

Installing and Starting Planck Locally

Before deploying applications, you need to install the Planck binaries, initialize the environment, and configure your local CLI profile.

1. Download and Extract the Binaries

Download the archive matching your machine from the releases page. For macOS (local development), install it under your home directory:

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

Next, add the bin directory to your shell configuration (~/.zshrc):

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

Reload your shell (source ~/.zshrc) and verify the binaries are accessible:

which planck planctl workbench

2. Initialize the Host Services

Run the system initialization. This is a one-time command that creates the directory layout, registers supervised services, and installs the internal identity database used by the Workbench:

sudo planctl system init

(On macOS, this registers and starts launchd background agents; on Linux it uses systemd.)

3. Create your CLI Developer Profile

Open your browser and navigate to the Workbench UI at http://localhost:2369.
Log in using the username admin and the default key, which is shown right under the Connect button.
Save this profile in your local configurations file at ~/.planctl/config.yaml so the command-line tool knows where to deploy your code:

profiles:
  - name: dev
    nodes:
      - server: http://127.0.0.1:2369
        uid: admin
        key: UGxhbmNrX0RlZmF1bHRfQWRtaW5fS2V5XzAwMTA=

Developer Experience: NodeJS vs. Zig on Planck

A common concern with co-locating application code inside the database process using WebAssembly is that it might make the code complex or low-level. In practice, writing handlers in Zig using the Schnell framework is highly comparable to writing standard Express routes.

Here is a side-by-side comparison of a simple route that fetches categories and returns them as HTML:

NodeJS and Express

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

Zig and 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 handles routing, request parsing, and response delivery. The build tool planctl automates the compilation of this code into WebAssembly, meaning you do not have to write manual WASM bindings or build configurations.

The Benchmark: Planck-Pizzahub

For a quick demonstration, we will use the planck-pizzahub performance benchmark located in the perf-compare directory. This project is ideal for getting started because it is completely self-contained. It requires no external integrations, which means you do not have to set up Google OAuth or Stripe keys to see it run.

You can clone the repository from perf-compare.

The repository contains two versions of the same service:

planck-pizzahub: A Zig application running as a WebAssembly module inside Planck.
express-pizzahub: A NodeJS and ExpressJS application running against a local MongoDB database.

Both implementations use the exact same seed dataset containing 17 categories and 201 products, and they serve the same HTML fragments formatted for the Datastar hypermedia framework.

Running express-pizzahub

First, let us get the NodeJS version up and running. Make sure you have MongoDB running locally, then run the following:

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

The Express application will start listening on port 4000. You can test it by sending a request:

curl http://127.0.0.1:4000/categories

Running planck-pizzahub

Next, let us build and deploy the Planck version. Open a new terminal and run these commands from the planck-pizzahub directory:

cd perf-compare/planck-pizzahub
planctl deploy --all --arch mono --profile dev

This command compiles the Zig source code into a WebAssembly module and uploads it to your local Planck server.

Once deployed, you need to create the database stores and indexes. Run the following commands:

planctl create store categories --profile dev
planctl create store products --profile dev

planctl create index products.ProductID --type i64 --profile dev
planctl create index products.CategoryID --type i64 --profile dev
planctl create index products.Name --type string --profile dev
planctl create index categories.CategoryID --type i64 --profile dev

With the database schema ready, you can now import the same seed data:

cd app/seed
planctl import --manifest import.categories.yaml --profile dev
planctl import --manifest import.products.yaml --profile dev

The Planck service will now be running on port 3020. You can test it using curl:

curl http://127.0.0.1:3020/categories

Running the Benchmark

Now that both servers are running and populated with the same dataset, we can run a performance comparison using a load testing tool like oha.

To test the NodeJS and MongoDB stack, run:

oha -z 6s http://127.0.0.1:4000/categories

To test the Planck stack, run:

oha -z 6s http://127.0.0.1:3020/categories

When you compare the results, you will notice a substantial difference.

Here is a comparison of typical results captured on a standard Apple M1 MacBook 8GB RAM and 256GB SSD under local testing:

Metric	Planck (WASM)	Node + Express + MongoDB	Ratio
Requests per second	24,949	5,433	4.59x
Average latency	2.00 ms	9.21 ms	4.60x faster
Fastest response	0.08 ms	2.26 ms	29x faster
Slowest response	54.65 ms	109.91 ms	2.0x better tail
Sustained throughput	94.24 MiB/s	20.49 MiB/s	4.60x
Success rate	100%	100%	same

This performance gain is a direct consequence of the zero-distance architecture. Because the Zig application is co-located within the Planck process, database queries are simple in-memory function calls instead of network round-trips over localhost TCP sockets. The tail latency is also significantly lower and more stable.

Exploring Advanced Features with pizzaqsr-hda-mono

While the pizzahub benchmark is a great way to verify raw performance, real-world applications require more complex features.

If you want to see how Planck handles real-time updates and third-party integrations, look at the pizzaqsr-hda-mono sample app in repo. This project acts as a reference implementation for a complete monolith, showcasing features such as:

Server-Sent Events (SSE): It leverages Planck's built-in SSE hub to push live order status updates directly to kitchen and delivery dashboards.
Third-Party Authentication: It implements Google OAuth for user sign-in.
Payments: It integrates Stripe checkout flows and handles Stripe webhook events.

You can deploy and run this sample application using the same planctl workflow. It serves as a blueprint for building modern hypermedia apps using Datastar and Planck.

Performance Comparison of C#, Node, Java, Go & Rust on k8s

Kamlesh Bambarde — Sun, 26 Nov 2023 07:52:34 +0000

In continuation to my earlier post about using Rust Language for sustainable cloud computing, here, in this post, I would like to present comparison of facts like the CPU & Memory utilisation by languages like C#, NodeJS, Java, Go & Rust on k8s.

To perform this comparative study, I developed very basic Rest Api's in all these languages that serve exactly similar kind of data. All these Rest Api's are built based on the project template of ASP.Net Core Web Api, yes, the WeatherForeCast, containerised, deployed to Kubernetes and exposed using NGINX Ingress Controller.

Frameworks Used

Language	Framework
C#	ASP.Net Core
Java	SpringBoot
Node	ExpressJS
Go	Fiber
Rust	Warp

Test Environment;

Apple MacBook Air M1 with 8GB RAM
Microk8s by Canonical
wrk for Stress Testing

k8s Deployment Resource Limits;

Language	Request CPU	Request Memory	Limit CPU	Limit Memory
C#	250m	32M	500m	64M
Java	250m	128M	500m	256M
Node	250m	32M	500m	64M
Go	250m	32M	500m	64M
Rust	250m	32M	500m	64M

Stress Test Parameters

Threads - 12
Connections - 400
Duration - 30 Seconds

Stress Test Results

Language	Total Requests	Throughput	Data Received	Transfer Rate
C#	451463	15006/sec	288MB	9.56MB
Java	57992	1928/sec	41MB	1.35MB
Node	104504	3472/sec	67MB	2.23MB
Go	595449	19815/sec	392MB	13.05MB
Rust	672391	22344/sec	467MB	15.52MB

Resource Utilisation in Idle and Stressed State

Language	Idle CPU	Idle Memory	Stressed CPU	Stressed Memory
C#	1m	35Mi	483m	45Mi
Java	1m	129Mi	500m	228Mi
Node	1m	30Mi	500m	41Mi
Go	1m	7Mi	465m	17Mi
Rust	0m	0Mi	352m	9Mi

Observations

All the Rest Api's that I deployed to k8s, k8s was able to spin up the pods, but not Java SpringBoot based Rest Api pod. k8s was failing to spin up the Java SpringBoot based Rest Api pod for [OOMKilled] error, I had to then increase the memory from request 32M to 128M and limit from 64M to 256M. Despite the fact that SpringBoot deployment was configured with more memory than other deployments, its worst in throughput.

To my pleasant surprise ASP.Net Core pod was able to run with request memory of 32M and limit memory of 64M and much better throughput as compared to SpringBoot. Microsoft has definitely done a tremendous job at improving .NET Runtime in terms of the memory requirements and its utilisation even the garbage collection post stress test was faster than Java.

In an idle state all the frameworks were consistently eating up 1m core of CPU and that's the need of GC background thread, where as Rust was 0m.

Go Fiber implementation was somewhere closer to Rust Warp implementation from throughput perspective, was consuming close to 25% more CPU.

Node Express based Rest Api was much better compared to SpringBoot based Api, almost double the throughput.

What can you build using Rust?

Rust can be used to develop applications for cloud, Microservices, Azure Functions, AWS Lambdas. There are number of Rust Crates (packages) available to build applications for cloud, some of the widely used ones are listed below.

Web Frameworks

ORM

Database Clients

SQLX (supports MS Sql, MySql, PostGres & SqlLite)

Additionally, both Amazon and Microsoft has sdk for Rust to utilise services from their respective cloud platforms. Microsofts Azure sdk for Rust is part of Azure organisation on GitHub, but it's, still under heavy development and not official yet.

Is it easy to adopt Rust?

No, not at all, Rust is a language that has a very steep learning curve, lot of new stuff at conceptual level.

Not very long ago, Java too, was considered little difficult adopt for people who were trying to shift from procedural languages to Java. But with proper trainings and mentoring, people gained the required level of skills, so, the same is applicable to Rust.

Conclusion

As you can clearly make out from the about test results, that Rust outperforms every other language & framework in both throughput and resource utilization.

Languages like, Java, C#.NET, JS on Backend have served their purpose in an era where the world was getting into the internet based apps from desktop based apps. Now, that most of the IT workloads are moving to Cloud, it has become imperative to use modern languages like Rust that uses less resources, saves compute cost on cloud and more importantly, emits less carbon which results in to a lesser impact to our planet.

You can get all the source code and k8s manifests in my Git Repository, request me in comments for the same.

Sustainable Cloud Computing Using Rust Language

Kamlesh Bambarde — Sun, 26 Nov 2023 07:51:45 +0000

Sustainable Cloud Computing is an ecologically conscious and sustainable method to utilise cloud computing resources. Its main objective is to reduce the energy consumption by various cloud services and thereby the environmental effect of data centers.
Sustainable cloud computing benefits not only the environment but also organisations that rely on cloud services. By using environmentally friendly Platforms/Frameworks/Languages to build their services to run on cloud platforms, businesses can align their IT infrastructure with their sustainability goals and potentially reduce operational costs. It’s also an essential part of the broader effort to address the environmental impact of the IT industry and promote a more sustainable future.
Following are some of the Key principals of Sustainable Cloud Computing, where Rust can help achieve maximum benefits.

Energy Efficiency
Resource Management

Rust Language
Rust, a systems programming language developed at Mozilla by Graydon Hoare back in 2006. It was heavily influenced by the ideas from functional programming like immutability and algebraic data types etc. Though, Rust was mainly developed as a replacement of C++, but over the period of time it has acquired a convenience of high-level languages, which makes it possible to be used for the development of services that run on cloud platforms.
Following are some of the reasons for which Rust is increasingly being used in the context of sustainable cloud computing:

Performance and Efficiency: Rust is made to guarantee memory safety while offering low-level control over system resources. It is therefore a cost-effective option for developing services that run under cloud environment. Efficiency is a significant consideration in sustainable cloud computing since it may assist reduce energy consumption and optimize resource usage.

Memory Safety: Rust’s ownership and borrowing model of memory management can significantly help eliminate issues like null pointer dereferences and data races. The memory safety provided by Rust, enables developers to fearlessly write concurrent code that is both safe and efficient. As a result, there may be less need for resource-intensive error handling and debugging, leading to more stable and dependable cloud services.

Energy Efficiency: Rust’s emphasis on performance frequently results in code that uses less energy. Rust can contribute to lowering the overall energy usage of cloud services by decreasing the computational resources needed to complete activities. This is one of the most impending reasons for choosing Rust over other languages to develop services that run on Cloud Platforms.

Reduce Resource Consumption: Rust’s resource management features can assist developers in making the best use of CPU, memory, and other resources, therefore reducing the environmental impact.

Scalability: Rust’s architecture makes it ideal for creating scalable and highly concurrent systems, which are critical in cloud computing environments. Minimising the number of CPUs and amount of RAM needed can help significantly reduce the overall environmental impact of cloud computing.
Long-Term Maintainability: Long-term software system sustainability is a component of sustainable cloud computing. Because of its robust type system and emphasis on memory safety, Rust can facilitate the evolution and maintenance of services that run in a cloud environment over time, minimising the need for resource-intensive rewrites or replacements.
Open Source Ecosystem: Rust has a strong open-source community and ecosystem, which can foster the development of sustainable cloud computing solutions and encourage collaboration on eco-friendly initiatives.

In the next part of we will look at the evidence of how Rust is better compared to other languages from the perspective of resource utilisation and efficiency.