.svg)
Offset-preserving replication from any source Apache Kafka cluster
Whether your Kafka source is self-hosted Kafka or a cloud provider, copy your data 1:1 to transition to WarpStream quickly and easily.
Replicate your primary Kafka cluster to a secondary WarpStream cluster and instantly flip over to the read replica if you have a hardware failure or networking issues, minimizing any downtime and data loss.
Offload analytical or batch jobs to isolated hardware. Scale read throughput infinitely and on demand in seconds. Set up dedicated clone clusters per team without impacting production workloads.
Orbit can provide tiered storage for any existing Kafka cluster that scales to massive read throughput with consistent performance. Reduce your storage costs by up to 24x.
Geographically distribute your data to read from the nearest read-only replica to reduce latency.
Don't see an answer to your question? Check our docs, or contact us directly.
Orbit is included as a value-added feature for all WarpStream Bring Your Own Cloud (BYOC) accounts and billed via our standard Bring Your Own Cloud (BYOC) billing metrics.
Since Orbit is embedded in the WarpStream Agents, there’s no need to opt-in to it. Orbit can be run (turned on and off) from within the WarpStream Console or via our Terraform provider.
Orbit is controlled via a simple YAML file that we provide. All you have to do is go to the Orbit section within WarpStream, paste in the YAML, save it and click the on-screen controls to change the status from Paused to Running. One instance of Orbit is needed per virtual cluster in WarpStream.
You can learn more about how Orbit was designed and how it works in our Orbit blog post.
WarpStream was built from the ground up around commodity object storage, whereas many other tiered storage implementations were bolted on after the fact. While these other tiered storage implementations can reduce storage costs, they incur steep performance penalties when consumers try to actually access tiered data.
WarpStream on the other hand stores data in object storage all the time with no tiering, and therefore provides consistently high performance regardless of whether the data being accessed is recent or historical.
You can read more in our blog post: Tiered Storage Won't Fix Kafka.
Orbit and Confluent Cloud Cluster Linking are very similar in that they both enable offset preserving replication between two Kafka-compatible clusters. The primary difference between the two is that Orbit is built into the WarpStream Agents, and therefore more tightly integrated with WarpStream.
In addition, Orbit is deployed as part of WarpStream's BYOC offering, whereas Cluster Linking is integrated into Confluent Cloud and Confluent Platform.
The fact that Orbit is built into the WarpStream Agents makes it feasible to use Orbit in any scenario where WarpStream BYOC is being deployed, whereas it may not have been possible to use Cluster Linking at all since Confluent Cloud would have no way to connect to source Kafka clusters running in the customer's environment without exposing them to the internet.
Lorem ipsum dolor sit amet, consectetur adipiscing elit.
