Sizing & pricing
What a vNode is, how pools work, and what things cost.
The vNode
One vNode is roughly 2 vCPU and 4 GiB of memory, and costs $129/month. That is the only unit and the only price — no plans, no tiers, no annual lock-in, and nothing metered after the fact.
Each vNode includes 50 GB of egress and 50 GB of state storage per month. Ingress is free.
The minimum environment is 4 vNodes ($516/month), because a cluster below that cannot run the platform components and leave anything useful for your work.
vNodes buy capacity, you decide what it runs
A vNode is generic streaming-platform capacity. You allocate it into pools, each dedicated to a purpose:
| Pool | What runs there | Sizing |
|---|---|---|
| System | Platform components — the operator, the agent, monitoring, log shipping | Fixed, ours |
| Flink | Your JobManagers and TaskManagers | Yours, any size |
| Kafka | Brokers, if you enable Kafka | Fixed: 6 vNodes |
This is why the catalogue can grow without your base price moving: a capability you do not turn on costs you nothing, and one you do turn on costs exactly the capacity it uses.
Why Kafka is a fixed 6 vNodes
Kafka's shape is its size — though not for the reason a classic Kafka cluster would give you. Durability here comes from S3, not from three brokers each holding their own copy of every partition: brokers are stateless, so losing one is a non-event for your data, not a replication event. Each broker still needs enough memory to keep a useful page cache — Kafka serves reads from it, and a starved broker is technically running and measurably slow.
So there is no slider. You choose whether Kafka runs; we choose how it is shaped. That is the same trade as everywhere else on this platform, and it is what lets us support one Kafka rather than every Kafka.
The trade this shape makes, stated once so it is not a surprise: produce latency is hundreds of milliseconds, because an acknowledgement means the data is in your bucket. Throughput and cost are unaffected — batching absorbs it — but a produce-and-wait request path will feel it. Connect your app to Kafka has the detail.
Sizing a Flink job
Two numbers matter and they interact:
- Parallelism — how many parallel subtasks the job runs.
- Task slots —
TaskManager replicas × slots per TaskManager.
Slots must be ≥ parallelism. A job that asks for more is accepted by Flink, deploys cleanly, and then waits forever for slots that will never exist. The wizard checks this before writing anything.
A reasonable starting point: parallelism 2, one TaskManager with 2 slots, 2 GiB memory. Raise parallelism when Grafana shows busy time sitting near 1000 ms/s — that means the task is the bottleneck rather than whatever it is reading.
What you cannot be charged for
- Overage. Beyond your included bundle, extra capacity is bought as prepaid packs. We never bill you after the fact for something you already used.
- Surprise line items. Monitoring, log shipping, the dashboard, the agent, support — all included in the vNode price. There is no CloudWatch equivalent on your bill.
- A trial you forgot to cancel. There is no trial. The first month is a real month at the real price, cancellable at any time, and we refund the unused remainder if you stop early.
Reducing spend
- Suspend an environment you are not using. Compute stops and the cost drops to roughly nothing; your Git configuration and S3 data stay. Note that Kafka messages do not survive a suspend — see Checkpoints & storage.
- Disable Kafka if you stopped using it — that is 6 vNodes back.
- Remove Flink capacity you are not scheduling onto.
All three are self-service, and none of them are blocked if your account is behind on payment. Stopping spend is never something we get in the way of.