Skip to main content
← Back

wasmCloud 2.3: wasmCloud Benchmarks, WASI P3 Canary & SQLX Native Async

The June 3, 2026 wasmCloud community call walks through the wasmCloud 2.3 release — Bailey Hayes demos configurable OpenTelemetry exporters and distributed trace propagation across multiple wash dev hosts, then tours the new bare-metal Hetzner benchmarking pipeline running Criterion and iai-callgrind on every release. The team previews the WASI Preview 3 canary image (P3 launch expected next week), Jeremy Fleitz walks the Kubernetes HPA alignment work for wasm runtime autoscaling, and Bailey closes with a clean SQLX component in Rust using Tokio's native-async backend, paving the way for a deeper host-component-plugins discussion driven by Liam Randall and Victor Adossi.

Key Takeaways​

  • wasmCloud 2.3 shipped trace propagation across hosts and workloads — running three wash dev instances with per-instance configs produced a single call chain in OpenTelemetry, including spans crossing non-WebAssembly hops
  • A configurable OTel exporter in the wash dev example uses Docker-Compose-style ${VAR} and ${file:...} syntax for both dev-host and workload values, with allowed-hosts enforcement on outbound calls
  • Test infrastructure moved to xtask — decoupling fixture builds from cargo closed a long tail of first-run papercuts and unblocked the new benchmarking pipeline
  • Every release now triggers a benchmark run on a tuned bare-metal Hetzner AMD Ryzen 5 host, with Criterion (wall-time) plus iai-callgrind (instruction counts via Valgrind) micro-benchmarks measuring HTTP invoke throughput, cold vs hot invocation, and P2 vs P3 paths
  • Maintainers can trigger comparison runs from a PR SHA against main, so performance-sensitive changes get a quantified A/B before merge
  • Namespace scoping landed on the runtime operator with regression tests against cluster-scoped roles — driven by financial-services and government environments that disallow cluster-wide deployments — alongside fuzz testing for the workload-spec serialization path
  • A WASI Preview 3 canary image is now published (wash OCI: canary-p3) and P3 launch is targeted for next week; the canary becomes the default canary once P3 ships
  • Kubernetes Horizontal Pod Autoscaler alignment is the next major Wasm-autoscaling work item — replacing the rudimentary built-in autoscaler with the standard HPA contract so Wasm workloads scale like container workloads
  • SQLX now works out of the box in WASI Preview 2 with the Tokio current_thread runtime — under 50 lines of code, a single tokio_unstable flag, and the WASI P2 socket stack underneath
  • Host component plugins + the component-model implements proposal are the path from "one Postgres binding" to multi-backend, runtime-routable services — but bindings remain static at the WIT level, so dynamic, fully-pluggable backends still require external infrastructure like PgBouncer at global scale

Chapters​

Meeting Notes​

Configurable OpenTelemetry Exporters and Trace Propagation​

Bailey opened the wasmCloud 2.3 walkthrough with the work to pass configuration secrets and environment variables straight into wash dev workloads. The repo's OpenTelemetry example ships a dev.yaml that splits dev-host values (such as the OTel exporter endpoint) from workload values (the environment variables and secrets the guest sees), using Docker-Compose-style ${VAR} and ${file:...} references. The example also exercises allowed-hosts enforcement — by default it reaches example.com and httpbin.org, and a missing allowed-hosts entry surfaces a clear error rather than silent failure.

On top of that, trace propagation now follows calls across multiple hosts and across non-Wasm workloads. In the demo, Bailey ran three wash dev instances of the same example component bound to ports 8000–8002, each with its own configurable backend address, producing a three-hop call chain where every span — across hosts, workloads, and the WASI HTTP boundary — rolled up into a single distributed trace. The setup is in the live dev.yaml and is replicable straight off the example.

xtask and the New Bare-Metal Benchmarking Pipeline​

Bailey then walked through one of the highest-impact internal changes: test fixture builds moved to cargo xtask. The reason is that cargo is "very, very specific about doing one thing well," and the fixture build (the wasmCloud test corpus of Wasm modules across multiple toolchains) kept tripping up first-time clones. Decoupling fixtures from cargo closed a long tail of beginner-reported papercuts and unblocked the benchmarking pipeline.

Every wasmCloud release now triggers a benchmark run on a hosted bare-metal Hetzner AMD Ryzen 5 host tuned for performance work. Two micro-benchmark suites run: Criterion (wall-time, HTTP invoke throughput, cold vs hot invocation, with P2 vs P3 matrices) and iai-callgrind — Valgrind's instruction-counting harness, much lower variance than wall-time and ideal for nanosecond-scale composition work. Maintainers can also trigger comparison runs from a PR SHA against main from the workflow UI, so performance-sensitive changes get an A/B before merge. The full runbook ships alongside the benchmarks — replicable benchmarks are the point — and adding new benches is a matrix entry.

Frank Schaffa asked whether OTel-enabled runs were measured. The micro-suite intentionally omits OTel to keep the runtime path "as close to pure component composition as possible," but adding a k6-style macro benchmark — which is the right shape for measuring OTel overhead — is the next item on the bench roadmap.

Namespace Scoping, Operator Fuzz Testing, and the WASI P3 Canary​

Bailey covered three operator-side updates. First, plugin-aware span names prefix the WASI interface (wasi:blob-store, wasi:keyvalue) onto host-plugin spans so it is obvious which interface is surfacing the trace — cleaner OTel output than the previous bare get-data style. Second, namespace scoping for runtime-operator deployments landed with a regression test that flags any cluster-scoped role going forward; Jeremy Fleitz noted that this was driven specifically by financial-services and government users who disallow cluster-wide namespacing. Third, fuzz testing runs continuously over the operator's workload-spec serialization and deserialization paths, hunting for panics around host-interface plumbing.

The biggest forward signal: a WASI Preview 3 canary image is now published as canary-p3 on the wash OCI repository (a host with WASI P3 enabled by default, no separate flag). Bailey says P3 launch is on track for as early as next week, after which the canary becomes the default canary and the separate -p3 tag goes away.

Roadmap: Kubernetes HPA Alignment and Q2 Status​

Bailey reviewed the Q2 project board and the imminent WASI P3 launch. Most items are landed or on track. Alex's WASI P3 PR in Wasmtime is in code review with the supporting wasm-tools work already merged. The benchmarking work is largely closed out — the macro-bench (k6-style) is the next prototype to take across the line. GC-enabled language support is the next major language-side item; the runtime can already produce hosts with GC, the work is wiring the flag through cleanly.

The headline roadmap item is Wasm autoscaling on Kubernetes. The current built-in autoscaler is "crude and rudimentary"; the goal is to align with the standard Horizontal Pod Autoscaler so that Wasm workloads scale exactly the way containers do. Jeremy Fleitz is taking the issue — first opened in January as a v2-on-Kubernetes journey item — and it is on track for this month.

SQLX in WASI Preview 2 with Tokio Native Async​

The most fun demo: SQLX running cleanly inside a WASI Preview 2 component. SQLX is a pure-Rust SQL toolkit that lets you write one query layer and point at SQLite, MySQL, or Postgres; the Postgres path is all-Rust, so it is a natural Wasm target. The demo component is under 50 lines, uses Tokio's current_thread runtime (no threads in WASI P2), and relies on the tokio::net crate enabled by the tokio_unstable cfg flag (P2 backend not yet stabilized in Tokio).

Bailey's PR adds SQLX as a CI fixture inside the SQLX repo — the "Beyoncé Rule" applied to upstream — validating it works against both MySQL and Postgres. Once the PR lands, the example becomes a reference template for Rust + Wasm + relational databases. The demo also closes a loop on GitHub-issue triage for LLM ergonomics: Bailey noted that stale "doesn't work" issues actively poison LLM-generated component code, so wasmCloud is sweeping its issue tracker and removing stale TODOs in the codebase to make AI-assisted development cleaner.

Host Component Plugins and the implements Proposal​

Liam Randall opened the most architectural discussion of the call: how do SQLX-style demos compose with the upcoming wasmCloud host component plugins and the component-model implements proposal? Bailey walked through it. The implements feature is a WebAssembly Component Model proposal already merged into the spec that lets a WIT world declare multiple stores of the same interface — a guest can express "I want this binding to act as other-cache." Host-side bindings are already wired into Wasmtime (Alex's recent change), and wasmCloud's workload spec gets an optional alias field so an interface import like other-cache is resolved against the host's plugin registry at runtime. The guest-side wit-bindgen work for implements is up next, so a single component can hold both an in-memory and a remote cache binding and pick between them at call time.

The important nuance: bindings remain static. Per-workload tenancy works — Team A's SQLX, Team B's SQLX, Team C's SQLX, each with their own configs — and a host component plugin can implement multiple backends, but the platform team has to know about those names ahead of time at host build. The fully dynamic, "pass any backend at any instance" model is not how WIT bindings work.

Dynamic Config and the PgBouncer Question​

Victor Adossi raised the natural follow-up: could a database load balancer (PgBouncer, PgCat) live inside a Wasm component? Bailey distinguished dynamic config (good — services can already import wasi:config and react to changes) from dynamic secrets (cool but harder — connection pools want their downstream resources verified before scheduling additional workloads).

The longer answer: once host component plugins, implements, and the broader Rust ecosystem (SQLX, Tokio, mio, socket2) are all in flight, you can compile a PgBouncer-class component. But for production database A/B migrations at global scale, Bailey would still keep PgBouncer external — wasmCloud hosts as cattle pointing at the real connection pool, deployed per edge or per zone. The "baby scale" Wasm-component PgBouncer is interesting; the global-scale one needs the long-running expressivity Wasm runtimes don't have yet. Victor and Bailey walked the longer chain (control-plane pause for slow queries, swap workloads, unpause) — interesting as a runtime-controlled control path, but a Q3-and-beyond conversation.

Yordis Prieto and Bailey closed with a riff on the WebAssembly Component Model word "world" (and Postgres's old "cluster" naming): the right names hide behind the right tooling abstractions, and over time the "world" you target will fade behind the component and platform you target.

wasmcloud.com Structured Data and YouTube AI Summaries​

Mid-call, Liam Randall walked through the wasmcloud.com side of the work: every page now emits JSON-LD structured data (Article / TechArticle / VideoObject) so LLMs and search engines can self-discover docs, tutorials, and community content. Every community meeting back through 2025 now has AI-generated summaries with chapter links surfaced both on wasmcloud.com and pinned on the wasmCloud YouTube channel, with reciprocal links between meeting pages and the docs they discuss landing as JSON-LD ships site-wide. This call is itself part of that effort.

WebAssembly News and Updates​

This call is a snapshot of WebAssembly converging on production Rust-ecosystem use. WASI Preview 3 is days from a launch vote — the last reference-implementation work (JCO's compliance pass, covered on last week's call) is in, and Alex's Wasmtime P3 change is in code review. The reachability of mainstream Rust crates is improving fast: SQLX, Tokio, mio, and socket2 all have working WASI P2 paths now, which is the right setup for the P3 leap. On the platform side, the bare-metal Hetzner benchmark suite plus per-PR comparison runs land continuous, replicable performance data — and the Kubernetes Horizontal Pod Autoscaler alignment work brings Wasm workload scaling into parity with container workloads. For ongoing webassembly news, follow the Bytecode Alliance and the WASI subgroup.

What is wasmCloud?​

wasmCloud is a CNCF project for building applications out of WebAssembly components and deploying them across cloud, edge, and Kubernetes clusters. The Wasm component model lets you write business logic in any supported language — Rust, Go, Python, TypeScript, C#, Java, and more — while the platform handles capabilities like HTTP, messaging, key-value storage, and observability through a pluggable host plugin architecture backed by Wasmtime. wash is the developer shell — build, run, deploy, debug — and the runtime operator lets you schedule Wasm workloads on Kubernetes the same way you schedule container workloads. With built-in OpenTelemetry observability, native WASI Preview 3 support landing, and a Kubernetes operator that integrates cleanly with HPA-aligned autoscaling, wasmCloud is the production substrate for WebAssembly on Kubernetes and the edge.

Topic Deep Dive: WASI Preview 3 and Native Async on the Runtime​

The throughline of the call is WASI Preview 3 and what changes when it lands. The canary image is already published; the upstream Wasmtime PR is in code review; the JCO reference implementation passed compliance last week. The SQLX demo is the first concrete payoff — a real Rust async crate stack (Tokio, mio, socket2) running on the WASI P2 backend today, and ready to take advantage of native async, streams, and futures the moment P3 ships. P3 is what unlocks a single guest component composing multiple backends through the implements proposal, and it is what makes host-component-plugin-routed services actually express the streaming and long-lived call patterns that databases, observability backends, and queue clients need. The wasmCloud roadmap calls for enabling P3 by default while keeping a disable flag, plus a hardening pass on the P3 path and a documentation refresh contrasting P2 and P3 — coordinated with a P3 launch blog post — so platform teams can plan their migration. The wash canary image (canary-p3) is the place to try it now.

Who Should Watch This​

This call is especially valuable for platform engineers evaluating Wasm autoscaling on Kubernetes (Jeremy's HPA-alignment update at 24:27), SREs and observability teams interested in low-overhead bare-metal performance benchmarking (Bailey's Hetzner pipeline at 14:30), and Rust developers building components against real database stacks (the SQLX + Tokio demo at 32:00). Architects weighing whether to extend the host with a plugin or ship a service inside a workload will get the most out of the host-component-plugins discussion at 37:09.

Up Next​

The next community calls land directly into the WASI Preview 3 launch. Watch for wasmCloud enabling P3 by default, a P3 hardening pass, the GC-enabled language support flag turning on, host component plugins moving from spec to implementation, and the k6-style macro benchmark joining the Criterion + iai-callgrind suite on the Hetzner bench host. The Q2 review at the end of the month is the moment to grade the autoscaling-on-Kubernetes work; expect demos.

Get Involved​

wasmCloud is a CNCF project and contributions are welcome. Join the community:

Full Transcript​

Read the complete transcript with speaker labels and timestamps:

Read the full transcript →