# Redpanda

> Managed Kafka-compatible streaming for durable event pipelines.

Redpanda is Watasu's streaming platform. It speaks the Kafka protocol, so existing Kafka clients work unchanged.

Use Redpanda when you need ordered, durable, replayable event streams — and when "publish to a topic, consume from a topic" is the right shape for your problem.

## Good fits

* analytics and product event pipelines
* audit and event-sourcing buses
* decoupling services that don't need synchronous responses
* ingestion buffers in front of slower downstream systems

## Create

```bash
watasu addons:create redpanda --app my-app
```

After attachment, your app receives Redpanda connection details (broker addresses, credentials) as config vars. Use any Kafka-compatible client library.

## Redpanda vs. Valkey

People reach for both for "queues." They're not the same:

|            | Valkey                        | Redpanda               |
| ---------- | ----------------------------- | ---------------------- |
| Ordering   | Best-effort                   | Strict per partition   |
| Durability | Optional, plan-dependent      | Built in               |
| Replay     | No                            | Yes (consumer offsets) |
| Best for   | Speed, ephemeral coordination | Durable event flow     |

If you'd lose sleep over dropped messages, you want Redpanda.

## Plan tiers

Three tiers, with a meaningful operational gap between Hobby and Standard:

* **Hobby** — single broker, **with throughput quotas** (produce + consume rate caps). Explicitly non-production. For development and small staging only.
* **Standard** — 3-broker replicated cluster, **no throughput quotas**, replication factor 3, rack-aware placement. The first production-grade tier.
* **Premium** — 8-broker cluster on larger pods, no throughput quotas, longer max retention.

Hobby's quotas are a hard ceiling — exceeding them causes throttling, not auto-scaling. Don't put production traffic on Hobby.

## Durability and "no backup API"

Redpanda is replicated and durable by design (`acks=all` + topic replication factor on Standard/Premium). Retention is controlled per-topic — you decide how long to keep messages, and consumers can replay from any retained offset within the retention window.

**There's no platform backup or restore API for Redpanda.** Unlike PostgreSQL/Valkey/ClickHouse, you can't "restore a deleted topic from yesterday's snapshot." If a topic is deleted or its retention window passes, the data is gone.

Design retention windows, downstream durability (consumers writing to a database or object storage), and topic deletion guards deliberately for your use case.

[View this page on the web](https://docs.watasu.io/addons/redpanda/)