Event Sourcing Competitor Scan — TypeScript Landscape
Status: Reconnaissance (spike-W2) Datum: 2026-04-16 Author: Marc Frost Purpose: Validate that “first ergonomic ES framework for TypeScript” is a real gap, not a delusion.
TypeScript / Node.js Landscape
Eventicle
- GitHub stars: ~150 (small community)
- Scope: event-bus + lightweight aggregate helpers
- Storage: pluggable, but no opinionated default
- Not a framework — a building-block library. Developer assembles storage, projections, read-models themselves.
- Position: closer to “CQRS building blocks” than “Marten for TS”
Castore
- GitHub stars: ~200
- AWS-focused (DynamoDB storage primary; others via adapters)
- Scope: event-store abstraction + commands + reducers
- Good type-safety, Zod-compatible
- Not full-stack — you bring your own HTTP framework, projections, and multi-tenancy
- Position: a typed event-store SDK, not a framework
Aerosync
- Commercial, enterprise-focused
- Not OSS, not comparable
@wix/event-sourcing, Hexagonal-Lime, etc.
- Smaller projects (< 50 stars), mostly experimental
- None have the full-stack breadth
Conclusion for Node/TS
There is no opinionated, full-stack, ergonomic ES framework in TypeScript. The landscape consists of:
- Libraries that require assembly (Eventicle, Castore)
- DynamoDB-specific tools (Castore, @wix/*)
- Experimental projects without production traction
The gap Kumiko targets is real.
Cross-Language References (the standards Kumiko borrows from)
Marten (C#, Postgres-native)
- The gold standard. Document + Event Store on Postgres
- Battle-tested: used by several financial and healthcare SaaS in production
- Projection lifecycles: Inline, Async, Live — exactly the model Kumiko plans
- C#-specific API (class-based aggregates with
Apply()methods) - What we steal: architecture, lifecycle model, projection-rebuild story
- What we improve: TypeScript-native ergonomics, declarative upcasters, progressive disclosure
Axon Framework (Java)
- Enterprise-heavy, Spring-style DI ceremony
- Excellent for large-scale distributed systems
- Poor fit for solo-dev or small-team adoption
- What we avoid: the complexity tax. Kumiko should feel lighter for single-app use
Rails Event Store (Ruby)
- Popular in Ruby community for DDD-heavy apps
- Simpler than Axon, more opinionated than Eventicle
- Good projection story but less emphasis on multi-tenancy
- What we note: Ruby devs liked “built on Postgres, no extra infra” — same positioning Kumiko targets
EventStoreDB
- Purpose-built event store (not a framework)
- Language-agnostic clients
- Good for very-high-volume
- Where it wins: Uber-scale event throughput
- Where Kumiko wins: no extra service to run, projections live next to events in Postgres
Commanded (Elixir)
- Minimalist, BEAM-native
- Not relevant as a competitor but instructive: simplicity + ergonomics wins community favor
Where Kumiko is Unique
| Capability | Eventicle | Castore | Marten | Axon | EventStoreDB | Kumiko |
|---|---|---|---|---|---|---|
| TypeScript-native | ✓ | ✓ | ✗ | ✗ | partial | ✓ |
| Postgres-native | partial | ✗ | ✓ | partial | ✗ | ✓ |
| Full-stack (HTTP + auth + multi-tenant) | ✗ | ✗ | partial | ✓ | ✗ | ✓ |
| Multi-tenant built-in | ✗ | ✗ | ✗ | partial | ✗ | ✓ |
| CRUD-shaped Level-1 API | ✗ | ✗ | ✗ | ✗ | ✗ | ✓ |
| Declarative upcasters | ✗ | ✗ | ✗ | ✗ | ✗ | planned |
| Progressive Disclosure docs | — | — | ✗ | ✗ | ✗ | planned |
| Real-time event subscriptions as first-class | partial | ✗ | ✗ | ✓ | ✓ | planned |
No single competitor has the full row. Kumiko’s niche is “Marten-caliber architecture, TS-native ergonomics, opinionated multi-tenant framework out of the box.”
Risk — Someone Else Gets There First
Scenario: A well-known TS maintainer announces a similar framework in Q2 2026.
Mitigation:
- Kumiko’s edge is the packaging (progressive disclosure, Level-1 CRUD feel) and framework breadth (auth, multi-tenant, search, SSE) — hard to replicate quickly
- Docs + samples are the defensive moat: great DX beats abstract architecture
- Ship early with a narrow-but-polished v1 rather than a broad-but-rough alpha
Assessment: Medium-probability / medium-impact. Not a reason to abandon the project.
What the Market is Asking For (GitHub issue evidence)
Recurring themes across Nest.js, tRPC, Prisma issues:
- “How do I add audit trail?” (answered with: custom hooks, brittle)
- “How do I do time-travel debugging?” (answered with: you can’t, check logs)
- “Can I rebuild read-models after schema change?” (answered with: run a script)
- “How do I handle optimistic concurrency across complex updates?” (answered with: version column, manual)
All of these are ES-native capabilities. If Kumiko delivers them as defaults, it addresses known pain in the TS ecosystem directly.
Go/No-Go Implication
GREEN. The gap is real, the differentiation is defensible, and the market evidence supports demand. Competitor landscape doesn’t reveal a show-stopping rival.