Managed Kafka and RabbitMQ in Switzerland, in the VPC.

Both engines move messages, and that is where the resemblance ends. What follows describes their own behaviour, independently of Hikube: that behaviour is what decides, not the provider.

• Must the message survive being read? Kafka keeps a log that several consumers re-read at their own pace; RabbitMQ removes the message from the queue once acknowledged
• Do you need to replay the past? This is the fastest test: replaying three days of events is native to Kafka and has no equivalent in a work queue
• Does order matter, and over what? Kafka guarantees order within a partition, so per partitioning key: not globally, which often surprises
• Is routing a business rule? RabbitMQ routes by exchange, key and headers; on Kafka, the sorting is application code
• How many consumers, and independent? Several groups reading the same thing without interfering is Kafka’s ground; one job consumed once by a pool of workers is RabbitMQ’s
• Both can coexist in the same tenant, and often do: an event log on one side, work queues on the other

Sizing uses the same instance grid as the managed databases, nano to 2xlarge, with the same ceiling: sizes are on the pricing page. A Kafka topic’s retention is paid in storage, not compute, and it is what grows the bill when thirty days are kept “just in case”. Topics and queues, schemas, ACLs, partitioning, producers and consumers stay on your side: the platform operates the brokers, not your message model. Two things are not published here and should be asked before you design: the engines’ version numbers, and the per-instance limits (throughput, partition count, message size).

As a managed database instance on the pricing page: nano (4 CHF/month) to 2xlarge (160 CHF/month). Those are the published database catalogue sizes, which include Kafka. RabbitMQ is the AMQP path of the same messaging product. There is no “version X” Kafka SKU.

Not if you take the managed service. Your Kubernetes apps remain clients. If you insist on running Kafka yourself on the cluster, that is possible on workers: it is no longer the managed product. Workers spread automatically, no DC choice.

Hidora SA operates the managed brokers, the three DCs and FR/EN support. You keep topics, queues, schemas, ACLs, producers and consumers. Terraform integration in preparation: today, Hikube API and console.

Line-of-business integration that must not leave Switzerland. Replacing a CLOUD Act bus. AMQP queues already there under VMware. Redis remains cache: that is not this product.

No. This is managed Kafka and RabbitMQ in the Swiss VPC, operated by Hidora SA. Not a global serverless bus, not Event Hubs, not a Kafka version number published here. Producers and consumers stay yours.