One week into public availability, the first add-on sheds its early-access label: Redpanda, Watasu’s managed streaming platform, is now open to all accounts.
Redpanda speaks the Kafka protocol — your existing Kafka client libraries, in any language, work unchanged. What it gives you is the thing every growing system eventually needs: ordered, durable, replayable event streams between services that shouldn’t be calling each other synchronously.
When a queue isn’t enough
A lot of teams start with “we’ll just push jobs through the cache” — and for fire-and-forget work, that’s fine. But the moment messages become facts — an order was placed, a payment cleared, a user deleted their account — you need guarantees a cache was never meant to give:
- Strict ordering per partition, so events replay in the sequence they happened
- Durability by design — on production tiers, every message is replicated across three brokers before it’s acknowledged
- Replay — consumers track their own offsets, so a new service can read history, and a buggy consumer can rewind and try again
A simple test we suggest: if losing a message would cost you sleep, it belongs in Redpanda. If it wouldn’t, a cache-backed queue is probably cheaper and faster.
Where this shape fits: product analytics pipelines, audit and event-sourcing buses, decoupling services that don’t need synchronous answers, and ingestion buffers in front of slower downstream systems.
Attach it like everything else
watasu addons:create redpanda --app my-appBroker addresses and credentials arrive in your app’s config vars; from there it’s standard Kafka tooling all the way down — producers, consumer groups, topics, offsets.
The tiers, plainly
- Hobby (€30–€60/mo) — a single broker with throughput quotas: hard caps on produce and consume rates. Exceed them and you get throttled, not auto-scaled. It exists for development and small staging, and we’ll say it directly: don’t put production traffic on it.
- Standard (from €300/mo) — production begins here: a 3-broker replicated cluster with replication factor 3, rack-aware placement, local NVMe, no quotas, and two weeks of retention to replay against.
- Premium — an 8-broker cluster on larger pods with longer retention, for when the firehose is the product.
Full specs and prices are on the pricing page.
A different durability model — on purpose
You’ll notice Redpanda has no backup API. That’s not an omission: a replicated log with per-topic retention is the durability model. Messages are acknowledged only once replicated, you decide per topic how long history stays, and any consumer can replay from any retained offset. Think of retention as your recovery window — set it to match how far back you’d ever need to rewind.
Get started
The Redpanda docs cover topics, retention, and the Valkey-vs-Redpanda decision in more depth. Attach one to a staging app, point a producer at a topic, and watch your services stop holding each other’s hands. Questions? info@watasu.io.