Redpanda Support Options: Redpanda Data, Community or Independent

Redpanda support comes from Redpanda Data for Redpanda Cloud and for self-managed Enterprise customers, from the community for the free Community Edition, and from independent providers for versions past end of support and for the operational work around the cluster. Redpanda supports each major release line for 12 months, so a self-managed cluster needs an upgrade at least once a year to stay covered.

What Redpanda Data supports

Redpanda is a Kafka API compatible streaming data platform written in C++, with no JVM and no ZooKeeper. There are three ways to run it. Redpanda Cloud, including Serverless, Dedicated and BYOC clusters in your own AWS, Azure or GCP account, is operated and supported by Redpanda. Self-managed Enterprise needs a licence key, unlocks enterprise features such as Tiered Storage, and comes with support plans that set target response times by priority. Community Edition is free and source-available, and its support is the community Slack and GitHub.

The 12-month support window

Redpanda's supported versions policy covers the current Enterprise major release line and all prior major release lines from the previous 12 months, which gives each major release a 12-month lifespan before it reaches end of support. During that time Redpanda ships maintenance releases on the latest line and backports critical bug fixes to earlier supported lines. After the end of support date, no further patch releases or bug fixes, including fixes for security vulnerabilities, are guaranteed, and technical support is limited to help with upgrading to a supported version.

That is a clear policy and a demanding one. Redpanda releases several major lines a year, so a cluster that was deployed and left alone is out of support within twelve months, contract or not.

The Redpanda incidents that actually page people

• Disk space alerts and blocked producers. Redpanda rejects writes when a broker's free space falls below its threshold, to protect itself. Retention set by time while throughput grew, or Tiered Storage uploads falling behind, is the usual cause.
• Tiered Storage and object storage problems. Uploads to S3 or another object storage bucket lag or fail because of permissions, throttling or network limits. Local disks fill, and consumers reading old data from a remote partition see high latency.
• Too many partitions for the hardware. Redpanda allocates memory per partition per core. A cluster sized for 5,000 partitions that now has 30,000 shows instability that looks random and is arithmetic.
• Leadership and partition imbalance. After a broker restart or a node replacement, partition leaders concentrate on a few brokers, and latency follows. Continuous data balancing is an enterprise feature, so Community clusters need this done by hand.
• Consumer lag that is not Redpanda's fault. Kafka clients behave the same way against Redpanda as against Kafka: rebalance storms, slow processing and misconfigured fetch settings cause lag that no broker tuning fixes.
• Node replacement in Kubernetes. A pod rescheduled onto a new node with an empty disk has to rejoin and re-replicate. Doing it with the wrong node ID or before decommissioning the old one leaves ghost brokers and under-replicated partitions.

Upgrading a Redpanda cluster

Redpanda upgrades are rolling and straightforward, with one rule that catches teams who have fallen behind: you upgrade one feature release at a time and cannot skip. A cluster three releases back needs three rolling upgrades, each completed and allowed to activate its new features before the next begins. Each broker is put into maintenance mode, which drains its partition leadership, then upgraded and restarted, and the cluster health check should be green before moving on. Check the licence too. Recent versions enforce the enterprise licence on enterprise features, so a cluster that has been using one without a valid key needs that resolved before the upgrade.

Redpanda support versus Kafka support

Teams moving from Apache Kafka often assume their Kafka support arrangement carries over, because the clients and the API are the same. The operational model is not. There is no ZooKeeper or KRaft controller quorum to look after, no JVM heap to tune and no page cache behaviour to reason about, because Redpanda manages its own memory and IO per core. In exchange there are Redpanda-specific things to know: the thread-per-core architecture and what it means for partition limits, maintenance mode, the rpk tooling, cluster configuration properties that replace broker config files, and Tiered Storage internals. A support provider should be fluent in both, since most Redpanda estates still have Kafka clients, Kafka Connect and sometimes a Kafka cluster running alongside during migration.

Where independent Redpanda support fits

• Community Edition in production, with no vendor to call.
• Enterprise clusters past the 12-month window, while the sequential upgrades are scheduled.
• Architecture and sizing: partition counts, replication factor, storage and whether Tiered Storage pays for itself at your data retention.
• Migrations from Apache Kafka, where the Kafka API makes clients easy and the operational model is different.
• The pipeline around the broker: Redpanda Connect, Kafka Connect, schema registry and the consumers, which vendor support plans do not operate for you.

AceMQ provides 24/7 Redpanda support with a 15-minute emergency SLA and named senior engineers, for self-managed clusters and Redpanda Cloud workloads. Examples: a broker latency remediation and a Tiered Storage assessment. For the wider picture, see message broker support options compared.