Skip to main content
← Back

wasmCloud Postgres Transactions & the Monorepo CI Debate

The June 18, 2025 wasmCloud community call pairs a live demo with a candid project-structure debate. Brooks Townsend demos new transaction support in the wasmcloud:postgres interface — committing several SQL updates atomically through a single WebAssembly component and showing how an invalid query rolls the whole thing back. The team then opens a wide-ranging discussion on the wasmCloud monorepo: whether to keep it and invest in monorepo tooling or split repositories along language lines, how to replace Nix-based CI with GitHub Actions, and how to make contributing to wasmCloud simpler.

Key Takeaways​

  • Postgres transaction support is landing in wasmCloud's Postgres capability provider. A Wasm component can now run several SQL statements that commit together or roll back together — modeled as a transaction resource with the same query signature as the existing interface, so converting existing code is mostly a matter of calling query on the transaction object.
  • No host upgrade required. Because wasmcloud:postgres ships as a standalone custom interface rather than being compiled into the wasmCloud host, the new transaction interface can roll out on its own lifecycle. The team plans to version-gate it (e.g. bumping the WIT interface) to avoid breaking changes.
  • The repo is effectively a monorepo built on Rust conventions. The wasmcloud/wasmcloud repository uses a cargo workspace plus Nix for complex CI, with wasmcloud/go and wasmcloud/typescript already split out because those languages carry their own structural expectations.
  • Yordis Prieto argued for keeping the monorepo — pay the layout cost up front, use Git sparse checkout, and write per-role contribution guides — since CI churn tends to stabilize once the dependency list settles.
  • Bailey Hayes proposed constraining the main repo to Rust, doing cargo-workspace-style development, and pulling everything that isn't Rust out into separate, language-aligned repositories.
  • Liam Randall argued either direction is roughly equal work — but that Nix should be dropped as the primary build engine in favor of normal GitHub Actions pipelines, while keeping the Nix flake around for reproducible development environments.
  • Tooling was weighed against its learning curve: monorepo build tools (Buck, Bazel), cargo workspace helpers (cargo-hakari, Guppy), and release automation (release-please) all came up, with the recurring caveat that adopting any of them means someone has to own the expertise.
  • No decision was made. The point was to surface options before the Q3 roadmap — the action items were to link the recording in Slack for feedback, explore replacing Nix actions with GitHub Actions, and draw a crate dependency graph to find simplification opportunities.

Chapters​

Meeting Notes​

DEMO: wasmcloud:postgres transaction support​

After a bit of group SQL collaboration to get the demo environment working, Brooks walked through new transaction support in the wasmCloud Postgres interface. The interface already supported querying, batch queries, and prepared statements; a community feature request asked for transactions, and Brooks put up a PR to gather feedback.

In the live demo, he set up a small table (the same one used by the example Postgres component in the wasmCloud repo) and updated the description of every row through a single transaction so that all updates succeed or none do. The interface models this as a transaction resource: you initiate a transaction on the client, then call query on the transaction object — the signature is identical to the regular interface, so existing code converts easily. Calling commit takes ownership and finalizes the work; if anything fails, the provider rolls back. To prove it, Brooks sent a deliberately invalid SQL statement and showed that the whole transaction failed cleanly with an actionable error and zero rows changed, even though the earlier valid queries had already been sent.

A nice property of the design: each query call doesn't need to resolve instantly — the provider ACKs it into the transaction and executes everything at commit time, keeping per-call latency low. The trade-off is that you don't get per-query return values mid-transaction. Brooks noted this is a good example of using a resource on the wRPC provider side, and a candidate for the documentation roadmap. Because wasmcloud:postgres is not built into the host, the new interface can ship on its own lifecycle, version-gated to avoid breaking changes.

DISCUSSION: the wasmCloud monorepo, thoughts and opinions​

To set the stage, Brooks noted that wasmcloud/wasmcloud is, for all intents and purposes, a monorepo — the home for wash, the host, all of the capability providers, and most examples — built on Rust conventions (a cargo workspace, with Nix handling the more complex CI, releases, and multi-target builds). A few projects have already moved out, namely wasmcloud/go and wasmcloud/typescript, because those languages expect to own their repository layout.

The core question: keep the monorepo or split it? The arguments against are that CI is complicated and the repo is unwieldy for new contributors. Yordis Prieto argued for keeping it — the layout cost is paid once, and techniques like Git sparse checkout plus role-oriented contribution guides keep it manageable; CI is always frustrating but stabilizes. Bailey Hayes proposed constraining the main repo to Rust and cargo-workspace-style development, pulling everything else out, while noting that producing the artifacts (gas/Wasm) keeps changing, so the build layer is a moving target.

Nix, GitHub Actions, and release pipelines​

Brooks demonstrated that wasmCloud already tries to gate actions — only running the wash action when specific crates or workflows change — but showed a case where a charts-only PR still triggered wash unit tests, because GitHub Actions can't express "this required check only needs to pass if it ran." Liam Randall made the case that either direction (lean in or split) is roughly equal effort, but that Nix should be dropped as the primary build engine in favor of normal GitHub Actions pipelines (run new pipelines in parallel, then cut over), while keeping the Nix flake for development environments. The team also discussed release-channel pain on GitHub, conventional commits, and release-please for changelogs and release PRs.

Tooling and next steps​

The group weighed monorepo build tools — Buck and Bazel, which are purpose-built for monorepos where Nix is not — against cargo workspace helpers like cargo-hakari (which uses Guppy under the hood to model the dependency graph). The recurring theme: any tool requires up-front expertise and an owner. ossfellow and Bailey reframed the real pain as CI discoverability — for example, where the wasmCloud container image is actually built — and suggested sketching the desired outcomes (traceable artifacts, push-button releases) before slicing the repo apart.

No decision was made in the call. The action items: link the timestamped recording in Slack for community feedback, explore replacing Nix actions with GitHub Actions, and analyze the crate dependency graph to find simplification opportunities — with a follow-up planned for the next meeting, alongside the Q3 roadmap.

WebAssembly News and Updates​

This call is a window into the day-to-day of running a CNCF WebAssembly project. On the feature side, transaction support for the Postgres capability provider extends what Wasm components can do with stateful backends — atomic multi-statement writes through a typed, version-gated interface that ships independently of the host. On the project-health side, the monorepo and CI discussion is the kind of maintainer conversation that rarely happens in public: how to keep contributing to wasmCloud approachable as the codebase grows, when to reach for monorepo tooling like Buck or Bazel, and how to trade Nix's reproducibility for the familiarity of GitHub Actions. For background on the runtime that the wasmCloud host builds on — and why it's the foundation of all that CI — see Wasmtime: a standardized runtime for wasmCloud. If you want to weigh in, the team explicitly invited feedback in the wasmCloud Slack and on the wasmcloud/wasmcloud repository.

What is wasmCloud?​

wasmCloud is a CNCF project that lets you build applications using WebAssembly components and deploy them anywhere — cloud, edge, or Kubernetes clusters. It uses the WebAssembly component model to let you write business logic in any supported language (Rust, Go, Python, TypeScript, C#) while the platform handles capabilities like HTTP, messaging, key-value storage, and — as in this call — SQL databases through a pluggable capability provider architecture. wasmCloud's host is built on Wasmtime and distributes workloads as OCI artifacts over NATS. With built-in OpenTelemetry observability and Kubernetes integration, wasmCloud bridges WebAssembly's portable, sandboxed execution model and production cloud-native infrastructure.

Topic Deep Dive: Capability Providers and the Postgres Interface​

The transaction demo is a good lens on how wasmCloud's capability providers work. A provider implements a typed WIT interface — here, wasmcloud:postgres — and a Wasm component calls that interface without knowing or caring how it's implemented underneath. Adding transactions meant introducing a transaction resource (a handle the component holds and calls methods on) on the wRPC side of the provider, mirroring how most Postgres client libraries model transactions. Crucially, the interface is a custom component-model contract that lives outside the host: it has its own lifecycle, so a new version can ship without upgrading the wasmCloud host, and it can be version-gated to keep existing components working. That separation — between the component's typed view of a capability and the provider's concrete implementation — is exactly what lets wasmCloud add database semantics like atomic transactions without escalating what the component itself is trusted to do.

Who Should Watch This​

This call is especially valuable for application developers using SQL from Wasm components, who'll want the transaction-support demo and the design rationale (8:24); maintainers and platform engineers wrestling with monorepo-vs-polyrepo trade-offs, CI gating, and release automation (the discussion from 19:21); and prospective contributors who want an honest look at why the wasmCloud repository is structured the way it is — and where it's headed (58:10).

Up Next​

The team explicitly deferred any decision: they'll link the timestamped recording in Slack, gather a week of community feedback, and revisit the monorepo and CI direction in the next meeting — timed to coincide with planning the Q3 roadmap. Concrete follow-ups to watch for: an experiment replacing some Nix-based actions with GitHub Actions, a crate dependency graph for wasmcloud/wasmcloud, and continued feedback on the wasmcloud:postgres transaction PR.

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 →