HN Showcase
Back to browse
Primatomic – Managed event sourcing with WASM fold functions

Primatomic – Managed event sourcing with WASM fold functions

by ptkenn·Mar 18, 2026·1 point·0 comments
Visit ProjectView on HN

AI Analysis

●●SolidBig BrainSolve My Problem

WASM views eliminate Kafka consumers, but EventStoreDB already does event sourcing.

Strengths
  • •WASM/WIT contract makes view logic portable across Rust, Go, Python, JS
  • •Four API calls to production—no Kafka clusters or consumer management
  • •S3 archival with automatic snapshots and read-your-write consistency
Weaknesses
  • •New platform means unproven reliability compared to established Kafka deployments
  • •WASM view debugging tooling likely immature for production troubleshooting
Target Audience

Backend engineers, distributed systems developers

Similar To

EventStoreDB · Materialize · ksqlDB

Post Description

Hey HN! I built Primatomic because setting up event sourcing infrastructure is a pain. You either stuff events into Postgres and hope for the best, or you're wiring together Kafka, projection services, and snapshot logic before you've written any business code.

Primatomic lets you append events to a log and deploy a pure fold function (compiled to WASM) that derives your read state. You query it over HTTP. The platform handles snapshotting, consistency (read-your-write via position tokens), and S3 event archival.

The WASM/WIT contract means your view logic is portable and testable outside the platform - write it in Rust, Go, Python, JS, anything that compiles to WASM.

I'd love feedback on the developer experience, docs, or anything that feels unclear. There's a free tier and I'm happy to hand out free credits if you want to test larger workloads.

Similar Projects