Billing accrues hourly, with a monthly-in-arrears invoicing cycle. If you de-provision resources that have accrued billed usage during the current month, billing will no longer accrue for these resources, but the billed usage accrued so far in the invoicing cycle will appear on your next invoice.
Subscription plan
A subscription is an agreement between you and StreamNative to pay for service on a particular schedule. In the current release, when you create an instance and a cluster on the StreamNative Cloud Console, you are automatically enrolled in the default Pay-As-You-Go subscription plan. For customers who have legacy clusters, submit a ticket to get assistance with moving your cluster to the updated subscription plan. If you want to provision a cluster withsnctl instead of on StreamNative Cloud Console, you’ll need to first create a subscription with snctl. For more information about snctl, see the StreamNative CLI (snctl).
For more information about viewing your invoices, what resources are included on your invoice, how to update your payment information, and more, see the billing documentation page.
Billing dimensions
StreamNative Cloud offers multiple cluster types. The billing dimensions vary by cluster type. The following table summarizes which capacity planning and charging models apply to each cluster type.| Cluster Type | Capacity Planning | Charging Unit | Charging Model |
|---|---|---|---|
| Serverless | Auto-scaled (ETU) | ETU (Elastic Throughput Unit) | Elastic — pay for actual usage |
| Dedicated Kafka (Public Preview) | TU (Throughput Unit) | RTU (Reserved Throughput Unit) | Reserved — pay for configured capacity |
| Dedicated Pulsar | CU + SU | CU + SU | Resource-based — pay for allocated resources |
| BYOC / BYOC Pro (Kafka clusters) | TU (Throughput Unit) | ETU (Elastic Throughput Unit) | Elastic — pay for actual usage |
| BYOC / BYOC Pro (Pulsar clusters) | CU + SU | ETU (Elastic Throughput Unit) | Elastic — pay for actual usage |
StreamNative storage and throughput are calculated in binary gigabytes (GB), where 1 GB is 2^30 bytes. This unit of measurement is also known as a gibibyte (GiB).
Serverless clusters
Serverless clusters adopt a throughput-based pricing model. The following table summarizes the billing dimensions for Serverless clusters.| Dimension | Unit of measure |
|---|---|
| Elastic Throughput Unit (ETU) | Cost per ETU per hour |
| Ingress (Data In) | Cost per GB |
| Egress (Data Out) | Cost per GB |
| Storage (Data Stored) | Cost per GB stored per hour |
Dedicated Kafka clusters (Public Preview)
Dedicated Kafka clusters are currently in public preview. Pricing for billing dimensions other than RTU is pending and subject to change during the preview phase.
| Dimension | Unit of measure |
|---|---|
| Reserved Throughput Unit (RTU) | Cost per RTU per hour |
| Ingress (Data In) | Cost per GB |
| Egress (Data Out) | Cost per GB |
| Storage - Latency Optimized | Cost per GB stored per hour |
| Storage - Cost Optimized | Cost per GB stored per hour |
Dedicated Pulsar clusters
Dedicated Pulsar clusters adopt a resource-based pricing model. The following table summarizes the billing dimensions for Dedicated Pulsar clusters.| Dimension | Unit of measure |
|---|---|
| Compute Unit (CU) | Cost per CU per hour |
| Storage Unit (SU) | Cost per SU per hour |
| Ingress (Data in) | Cost per GB |
| Egress (Data out) | Cost per GB |
| Storage (Data stored) | Cost per GB stored per hour |
BYOC & BYOC Pro clusters
BYOC & BYOC Pro clusters adopt a throughput-based pricing model and are charged based on actual throughput usage in Elastic Throughput Units (ETUs). How you configure the cluster’s reserved capacity depends on the cluster type:- Kafka clusters: You configure the reserved capacity in Throughput Units (TUs).
- Pulsar clusters: You configure the reserved capacity using Compute Units (CUs) and Storage Units (SUs).
| Dimension | Unit of measure |
|---|---|
| Elastic Throughput Unit (ETU) | Cost per ETU per hour |
Throughput Unit (TU)
A Throughput Unit (TU) is a capacity planning abstraction that represents a standardized amount of throughput capacity. TUs allow you to configure cluster capacity without managing infrastructure details such as CPU, memory, or broker counts. Each TU represents the following capacity:| Dimension | Capacity per TU |
|---|---|
| Ingress (Data In) | 25 megabytes per second (MBps) |
| Egress (Data Out) | 75 megabytes per second (MBps) |
| Data Entries | 2,500 entries per second |
- Reserved Throughput Unit (RTU): For Dedicated Kafka clusters, you are charged for the number of TUs you reserve when configuring the cluster. This is a fixed charge regardless of actual usage. See RTU for details.
- Elastic Throughput Unit (ETU): For BYOC and BYOC Pro Kafka clusters, you configure TUs as the reserved capacity, but you are charged based on actual throughput usage. See ETU for details.
BYOC Pulsar clusters use CU/SU for capacity planning instead of TUs, but are still charged by ETU based on actual usage.
Elastic Throughput Unit (ETU)
Elastic Throughput Units (ETUs) are the basis for billing clusters that adopt a throughput-based pricing model, including Serverless clusters and BYOC (and BYOC Pro) clusters in StreamNative Cloud. ETUs provide a flexible, scalable approach to resource allocation and pricing.How ETUs Work
Clusters adopting ETUs are elastic and have a minimum number of ETUs. They can automatically scale up to a maximum capacity based on your workload. The minimum ETUs define the baseline capacity of your cluster, which is the minimum amount you are billed for even when the cluster is idle. The maximum capacity is defined in terms of ETUs and governs the peak resources your StreamNative cluster can use. However, you are only billed for the actual capacity used in a given hour, up to this maximum. To determine the number of ETUs used in a given hour, the billing system monitors the actual consumption across several dimensions:- Ingress (Data In): This dimension measures the volume of data being written to your cluster. It is calculated as the total amount of data (in bytes) ingested into the cluster per second.
- Egress (Data Out): This dimension measures the volume of data being read from your cluster. It is calculated as the total amount of data (in bytes) retrieved from the cluster per second.
- Data Entries: This dimension counts the number of entries processed by the cluster per second. An entry represents a collection of messages batched together by either Pulsar or Kafka client. It includes both produce and consume operations.
Serverless ETU Capacity and Limits
Each Serverless ETU represents a certain capacity across different dimensions. Here’s a breakdown of what one Serverless ETU provides:| Dimension | ETU Capacity |
|---|---|
| Ingress (Data In) | 5 megabytes per second (MBps) |
| Egress (Data Out) | 15 megabytes per second (MBps) |
| Data Entries | 500 entries per second |
| Dimension | Maximum Capacity |
|---|---|
| Ingress (Data In) | 100 MBps |
| Egress (Data Out) | 300 MBps |
| Data Entries | 10,000 per second |
BYOC ETU Capacity and Limits
The following outlines what is included in one ETU| Dimension | ETU Capacity |
|---|---|
| Ingress (Data In) | 25 megabytes per second (MBps) |
| Egress (Data Out) | 75 megabytes per second (MBps) |
| Data Entries | 2500 entries per second |
Determining ETU Usage
To estimate your ETU usage, you can monitor your cluster’s performance across the three dimensions mentioned above. Your ETU consumption for a given hour will be based on the highest usage across these dimensions, relative to the capacity provided by one ETU. For example, if in one hour your Serverless cluster uses:- 20 MBps ingress (4 ETUs worth)
- 45 MBps egress (3 ETUs worth)
- 1,500 data entries per second (3 ETUs worth)
- 100 MBps ingress (4 ETUs worth)
- 100 MBps egress (1 ETUs worth)
- 12,500 data entries per second (5 ETUs worth)
Reserved Throughput Unit (RTU)
Dedicated Kafka clusters and RTU-based billing are currently in public preview. Pricing details may change during the preview phase.
How RTUs Work
When you create or resize a Dedicated Kafka cluster, you specify the number of Throughput Units (TUs) to reserve. Each reserved TU is billed as one RTU. Your cluster is provisioned with the corresponding capacity, and you are charged for the reserved amount at a fixed hourly rate. RTUs abstract away infrastructure details. You do not need to configure brokers, CPUs, or memory — you simply specify the desired throughput capacity in TUs.RTU Capacity
Each RTU provides the same capacity as one Throughput Unit (TU):| Dimension | Capacity per RTU |
|---|---|
| Ingress (Data In) | 25 megabytes per second (MBps) |
| Egress (Data Out) | 75 megabytes per second (MBps) |
| Data Entries | 2,500 entries per second |
RTU Limits
- Minimum: 1 RTU per cluster
- Self-service maximum: 20 RTUs per cluster (configurable via the Cloud Console)
- Beyond 20 RTUs: Contact StreamNative sales for larger configurations
RTU Scaling
You can adjust the number of RTUs for your Dedicated Kafka cluster using the TU slider in the StreamNative Cloud Console. RTU values are integers (whole numbers only).Changing the number of RTUs triggers a cluster reconfiguration. Allow sufficient time between scaling operations for the reconfiguration to complete.
CU and SU
Dedicated Pulsar clusters (formerly Hosted) are scaled using Compute Units (CUs) and Storage Units (SUs). These units provide a standardized way to allocate and manage resources for your Dedicated Pulsar clusters.CU and SU apply to Dedicated Pulsar clusters only. For Dedicated Kafka clusters, see Reserved Throughput Unit (RTU).
Compute Units (CUs)
- Definition: One CU represents a unit of compute resources, specifically 2 CPUs and 8 GB RAM.
- Usage: CUs are used to scale all stateless components in your cluster, primarily the brokers.
- Scaling: You can adjust the number of CUs to increase or decrease the processing power of your cluster.
Storage Units (SUs)
- Definition: One SU represents a unit of storage resources, specifically 2 CPUs, 8 GB RAM, and 1 TB disk.
- Usage: SUs are used to scale all stateful components in your cluster, including BookKeeper and ZooKeeper.
- Scaling: Adjusting the number of SUs allows you to manage the storage capacity and performance of your cluster.
Billing and Resource Allocation
The number of CUs and SUs used by a StreamNative cluster determines the total resources allocated. Charges for CUs and SUs accrue each hour based on the allocated resources. You can expand or shrink your cluster by adding or removing CUs and SUs. When you modify the cluster capacity, you are billed for the new resource allocation starting from the next hour following the change.Limits per CU and SU
CUs and SUs determine the capacity of a StreamNative cluster. For a StreamNative Cloud cluster, the expected performance for any given workload is dependent on a variety of dimensions, such as message size and number of partitions. Use the following guidelines to determine the minimum number of CUs and SUs to use for a given workload, how to monitor a dimension, and suggestions to reduce your use of a particular dimension.These dimensions provide guidelines for capacity planning. The ability to fully utilize these dimensions depends on the workload and utilization of other dimensions.
| Dimension | Guideline per CU | Details |
|---|---|---|
| Ingress | 50 MBps | Number of bytes that can be produced to the cluster in one second. To reduce usage on this dimension, you can compress your messages. lz4 is recommended for compression. |
| Egress | 150 MBps | Number of bytes that can be consumed from the cluster in one second. To reduce usage on this dimension, you can compress your messages and ensure each consumer is only consuming from the topics it requires. lz4 is recommended for compression. |
| Requests (aka Data Entries) | 10,000 per second | Number of data entries (each entry is a batch of messages batched at the client side) that can be produced to and consumed from the cluster in one second. To reduce usage on this dimension, you can adjust producer batching configurations and shut down otherwise inactive clients. |
Billing model comparison
StreamNative Cloud uses three billing models depending on your cluster type. The following table compares the key differences.| Aspect | ETU (Elastic Throughput Unit) | RTU (Reserved Throughput Unit) | CU/SU (Compute/Storage Unit) |
|---|---|---|---|
| Applies to | Serverless, BYOC / BYOC Pro | Dedicated Kafka (Public Preview) | Dedicated Pulsar |
| Capacity planning | Auto-scaled (Serverless), TU-based (BYOC Kafka), or CU/SU-based (BYOC Pulsar) | TU-based | CU + SU based |
| Charging | Actual usage (elastic) | Reserved capacity (fixed) | Allocated resources (fixed) |
| Scaling | Automatic | Manual (1-20 self-service) | Manual |
| Minimum billing | 1 ETU | 1 RTU | Varies by cluster configuration |
Organizations created prior to February 6th, 2026 still use CU/SU-based pricing for BYOC clusters. All BYOC clusters created on or after this date use ETU-based pricing.
Dedicated Kafka clusters (RTU)
With Dedicated Kafka clusters, you configure the cluster capacity in Throughput Units (TUs) and are charged for the number of TUs reserved as RTUs. Billing is at a fixed hourly rate regardless of actual usage. You do not need to manage infrastructure details — capacity is expressed entirely in TUs.Dedicated Pulsar clusters (CU/SU)
With Dedicated Pulsar clusters, you are billed based on the number of CUs and SUs allocated to your cluster. You determine the capacity at creation by specifying the number of brokers and bookies. If your cluster uses less capacity than what you configure, you still pay the same amount.Serverless clusters (ETU)
Serverless clusters are elastic. You provision a cluster with a fixed maximum capacity, but billing is based on actual usage, subject to a minimum of 1 ETU, even when no workloads are actively running. Costs scale up only as consumption increases and will never exceed the configured maximum capacity.BYOC and BYOC Pro clusters (ETU)
All BYOC clusters are charged by ETU based on actual throughput consumption. A minimum charge of 1 ETU applies even when no workloads are running. As consumption increases, billing scales with actual throughput usage. Your cluster has no predefined maximum capacity. Capacity planning differs by cluster type: BYOC Kafka clusters use Throughput Units (TUs) to configure reserved capacity, while BYOC Pulsar clusters use Compute Units (CUs) and Storage Units (SUs).Ingress and Egress
StreamNative Cloud charges for data transfer in two directions:- Ingress: Data transferred into your Serverless and Dedicated clusters.
- Egress: Data transferred out of your Serverless and Dedicated clusters.
- Data produced to topics
- Data consumed from topics
- Replication traffic between clusters
- Admin operations (e.g., topic creation, subscription creation)
- Use compression for message payloads
- Implement efficient batching strategies
- Minimize unnecessary data transfers
For BYOC (Bring Your Own Cloud) clusters, StreamNative Cloud does not charge for data transfers. These resources are hosted and billed directly by your cloud provider, so you’ll need to refer to your provider’s pricing for these costs.
Storage
StreamNative Cloud charges for the total volume of data stored in your Serverless and Dedicated clusters. Here are key points to understand about storage billing:- Pre-replication volume: Billing is based on the pre-replication volume of data. This means you’re charged for the actual data you store, not the replicated copies.
- Replication factor: StreamNative Cloud uses a built-in replication factor of 3 for high availability. While this triples the actual storage used, you’re only billed for the pre-replication volume.
- Billing calculation: Storage is billed based on the average volume of data stored over each hour, measured in gigabytes (GB).
- Retention policy: To optimize storage costs, you can configure retention policies for your topics. These policies can automatically delete data after a specified period or when certain size limits are reached.
- Compaction: For topics that only need to retain the latest value for each key, you can use compaction to reduce storage usage while preserving the most recent updates.
For Bring Your Own Cloud (BYOC) clusters, StreamNative Cloud does not charge for data storage. These resources are hosted and billed directly by your cloud provider.
Functions and Connectors
StreamNative Cloud charges for functions and connectors based on the Function Processing Units (FPUs) they consume. This pricing model applies to all Pulsar cluster types: Serverless, Dedicated, and BYOC (including BYOC Pro). An FPU represents a unit of compute resources, specifically 2 CPUs and 8 GB of RAM, dedicated to running functions or connectors. The charge for functions and connectors is based on the number of FPUs allocated and the duration of their usage. Key points about function and connector billing:- Consistent across cluster types: The FPU-based billing model is uniform across all Pulsar cluster types, ensuring consistency in how you’re charged for these components.
- Resource allocation: When you deploy a function or connector, you specify the resources it requires. StreamNative Cloud then allocates the appropriate number of FPUs based on this specification.
- Usage-based billing: You are billed for the FPUs allocated to your functions and connectors for as long as they are running. This means you only pay for the resources you use.
- Scalability: If your functions or connectors auto-scale, the billing automatically adjusts to reflect the increased or decreased FPU usage.
- Monitoring and optimization: You can monitor your function and connector usage in the StreamNative Cloud Console to optimize your resource allocation and manage costs effectively.
Consumption Units and Support Units
All StreamNative Cloud billing dimensions are calculated in StreamNative Consumption Units. Your overall charge for StreamNative Cloud usage will be equal to the total number of Consumption Units multiplied by the cost of that unit. The support plan purchased from StreamNative is also based on the Support Units. Your overall support cost will be the total number of Support Units multiplied by the cost of that unit.| Unit | Price | Description |
|---|---|---|
| StreamNative Consumption Unit | $0.1 | A Consumption Unit captures your StreamNative Cloud usage based on underlying metrics such as Compute Units (CUs), Storage Units (SUs), Reserved Throughput Units (RTUs), Elastic Throughput Units (ETUs), data stored, data in, and data out. |
| StreamNative Support Unit | $0.1 | A Support Unit captures your StreamNative Support costs based on your support plan. The support plan is a separate and optional purchase item. |
Pricing dimensions
This section describes pricing dimensions for Serverless, Dedicated Kafka, Dedicated Pulsar, and BYOC clusters.Pricing dimensions for Serverless clusters
The following table outlines the prices for usage dimensions for Serverless clusters.| Dimension | Consumption Units | Price |
|---|---|---|
| Elastic Throughput Unit (ETU) ($/hour) | 1 ETU/hour = 1 Consumption Unit | $0.10 |
| Ingress (Data In) ($/GB) | 1 GB = 1.3 Consumption Units | $0.13 |
| Egress (Data Out) ($/GB) | 1 GB = 0.4 Consumption Unit | $0.04 |
| Storage (Data Stored) ($/GB-Month) | 1 GB-Month = 0.9 Consumption Unit | $0.09 |
Pricing dimensions for Dedicated Kafka clusters (Public Preview)
Dedicated Kafka clusters are in public preview. Pricing for Data In, Data Out, and Storage dimensions is pending and subject to change during the preview phase.
| Dimension | Consumption Units | Price |
|---|---|---|
| Reserved Throughput Unit (RTU) ($/hour) | 1 RTU/hour = 7.5 Consumption Units | $0.75 |
| Ingress (Data In) ($/GB) | Pending | Pending* |
| Egress (Data Out) ($/GB) | Pending | Pending* |
| Storage (Data Stored) ($/GB-Month) | Pending | Pending* |
*Pricing for Data In, Data Out, and Storage dimensions is pending and subject to change during the preview phase.
Pricing dimensions for Dedicated Pulsar clusters
The following table outlines the prices for usage dimensions for Dedicated Pulsar (formerly Hosted) clusters.| Dimension | Consumption Units | Price |
|---|---|---|
| Compute Unit (CU) ($/hour) | 1 CU/hour = 2.4 Consumption Units | $0.24 |
| Storage Unit (SU) ($/hour) | 1 SU/hour = 3 Consumption Units | $0.30 |
| Ingress (Data In) ($/GB) | 1 GB = 1.3 Consumption Units | $0.13 |
| Egress (Data Out) ($/GB) | 1 GB = 0.4 Consumption Unit | $0.04 |
| Storage (Data Stored) ($/GB-Month) | 1 GB-Month = 0.9 Consumption Unit | $0.09 |
Pricing dimensions for BYOC clusters
The following table outlines the prices for usage dimensions for BYOC clusters.| Dimension | Consumption Units | Price |
|---|---|---|
| Elastic Throughput Unit (ETU) ($/hour) | 1 ETU/hour = 5 Consumption Unit | $0.50 |
Pricing dimensions for Functions and Connectors
The following table outlines the prices for usage dimensions for Functions and Connectors.| Dimension | Serverless | Dedicated | BYOC |
|---|---|---|---|
| Functions (FPU) ($/hour) | $0.18 | $0.18 | $0.10 |
Pricing models
You can either pay as you go or make an annual commitment. Discounts based on usage are available with annual commitments.Annual commitments
StreamNative Cloud offers the ability to make a commitment to a minimum amount of spend over a specified time period. This commitment gives you access to discounts and allows you to use this commitment across the entire StreamNative Cloud stack, including any StreamNative cluster type, connectors, functions, and support. If you use more than your committed amount, you can continue using StreamNative Cloud without interruption. You will be charged at the on-demand price for usage beyond the committed amount until the end of your commitment term. Commitments are minimums, and there is no negative impact to exceeding your committed usage. If you exceed this minimum, overage charges will be billed to the payment method set for your organization. Contact StreamNative to learn more about annual commitments, or review these topics.- Get Started with StreamNative Cloud on the AWS Marketplace with Commitments
- Get Started with StreamNative Cloud on the Google Cloud Marketplace with Commitments
Pay-As-You-Go
With the Pay-As-You-Go pricing model, you can sign up and pay monthly in arrears. If you sign up for StreamNative Cloud directly through StreamNative, your organization will be on the Pay-As-You-Go billing model by default. The Pay As You Go billing model is also available on the Cloud Marketplace channels. For more information on the cloud provider Marketplace integrations, see:- Get Started with StreamNative Cloud on the AWS Marketplace with Pay-As-You-Go
- Get Started with StreamNative Cloud on the Google Cloud Marketplace with Pay-As-You-Go
Pay-As-You-Go billing schedule
This section describes the billing schedule for the Pay-As-You-Go pricing model.Monthly, billed by StreamNative
When you sign up for StreamNative Cloud service by adding your credit card details in the StreamNative Cloud Console, you are billed monthly. At each billing cycle, on the first day of each month, all usage for the previous month is aggregated, invoiced, and charged in arrears on the credit card used to sign up for the service. All usage is expressed and charged in US dollars only.Monthly, billed through Marketplace
- Typically, marketplaces invoice you in arrears on the first day of each month. However, there are exceptions, such as in the case of the Google Cloud billing cycle.
- AWS marketplace only accepts integer usage. If your usage is smaller than the billing unit, the user is still charged at the billing unit price.
Pricing examples
This section provides pricing examples for different cluster types, functions, and connectors.The examples below estimate service costs based on a normalized monthly time frame. It assumes there are 730 hours in a month ((365 days * 24 hours) / 12 months in a year). The actual hours in a given billing period will vary slightly.
Pricing example for a Dedicated Kafka cluster (Public Preview)
Dedicated Kafka clusters are in public preview. This example covers RTU pricing only. Pricing for Data In, Data Out, and Storage dimensions is pending and subject to change.
- RTU: The total Consumption Units are
5 RTUs x 7.5 Consumption Units / RTU-hour x 730 hours = 27,375 Consumption Units
27,375 Consumption Units x $0.10 per Consumption Unit = $2,737.50 per month.
Additional charges for Data In, Data Out, and Storage will apply once pricing for those dimensions is finalized.
Pricing example for a Dedicated Pulsar cluster
On StreamNative Cloud, a minimum Dedicated Pulsar cluster consists of 2 brokers and 3 bookies. Each broker consumes 0.5 compute units per month and each bookie consumes 0.5 storage units per month. Therefore, the minimum cost for a Dedicated Pulsar cluster is about
$505 per month.- 3 brokers, each with 2 CUs
- 3 bookies, each with 2 SUs
- 200 GB data in
- 200 GB data out
- 200 GB data retained
-
CU: The total Consumption Units are
6 CUs x 2.4 Consumption Units / CU-hour x 730 hours = 10,512 Consumption Units -
SU: The total Consumption Units are
6 SUs x 3 Consumption Units / SU-hour x 730 hours = 13140 Consumption Units -
Data in: The total Consumption Units are
200 GB x 1.3 Consumption Units / GB = 260 Consumption Units -
Data out: The total Consumption Units are
200 GB x 0.4 Consumption Unit / GB = 80 Consumption Units -
Data stored: The total Consumption Units are
200 GB-Month x 0.9 Consumption Unit / GB-Month = 180 Consumption Units
24,172 Consumption Units x $0.10 per Consumption Unit = $2417.2.
Pricing example for a Serverless cluster
Serverless clusters are billed based on actual usage of resources, without the need to provision specific compute or storage units upfront.
- Average write throughput (Ingress): 1 MBps
- Average read throughput (Egress): 3 MBps
- Average entry size (batch size at the client side): 64 KB
- Retention: 7 days
- the total Data-Stored for 7-days retention is
1 MBps x 60 x 60 x 24 x 7 = 604,800 MB = 604,800 / 1024 = 590.625 GB. - the total Data-In in a month is
1 MBps x 60 x 60 x 730 = 2,628,000 MB = 2,628,000 / 1024 = 2,566.21 GB. - the total Data-Out in a month is
3 MBps x 60 x 60 x 730 = 7,884,000 MB = 7,884,000 / 1024 = 7,699.22 GB.
- ETUs by ingress:
1 MBps / 5 MBps/ETU = 0.2 ETUs - ETUs by egress:
3 MBps / 15 MBps/ETU = 0.2 ETUs - ETUs by data entries:
(1 MBps + 3 MBps) / 64 KB/entry / 500 entries/ETU = 0.128 ETUs
max(0.2, 0.2, 0.128) = 0.2 ETUs.
Let’s calculate the total consumption units used by this cluster.
- ETU: The total Consumption Units are
0.2 ETUs x 1 Consumption Unit / ETU-hour x 730 hours = 146 Consumption Units - Data in: The total Consumption Units are
2,566.21 GB x 1.3 Consumption Units / GB = 3,336.073 Consumption Units - Data out: The total Consumption Units are
7,699.22 GB x 0.4 Consumption Unit / GB = 3,079.688 Consumption Units - Data stored: The total Consumption Units are
590.625 GB x 0.9 Consumption Unit / GB = 531.5625 Consumption Units
146 + 3,336.073 + 3,079.688 + 531.5625 = 7,093.3235 Consumption Units x $0.10 per Consumption Unit = $709.33.
Pricing example for a BYOC Cluster
BYOC Latency-Optimized Clusters and Cost-Optimized Clusters are billed based on actual throughput.
- Average write throughput (Ingress): 50 MBps
- Average read throughput (Egress): 150 MBps
- Average entry size (batch size at the client side): 64 KB
- Retention: 7 days
- ETUs by ingress:
50 MBps / 25 MBps/ETU = 2 ETUs - ETUs by egress:
150 MBps / 75 MBps/ETU = 2 ETUs - ETUs by data entries:
(50 MBps + 150 MBps) / 64 KB/entry / 2500 entries/ETU = 1.28 ETUs
max(2, 2, 1.28) = 2 ETUs.
Let’s calculate the total consumption units used by this cluster.
- ETU: The total Consumption Units are
2 ETUs x 5 Consumption Unit / ETU-hour x 730 hours = 7300 Consumption Units
7300 Consumption Units x $0.10 per Consumption Unit = $730.
Pricing Example for Pulsar Functions and Connectors
Pulsar functions and connectors are billed based on the Function Processing Unit (FPU). You can convert the CPU and memory usage of your functions and connectors to FPUs based on the following formula:max((CPU / 2),(Mem (in GB) / 8))
For example, if you specify 1 CPU and 1 GB memory for a function, the total FPU for this function is max(1 / 2,1 / 8) = 0.5 CU.
If you have a Dedicated cluster on StreamNative Cloud, running an entire month, with
- 32 functions, each with 0.5 CPU and 1 GB memory
- 20 connectors, each with 1 CPU and 1 GB memory
32 x max((0.5 / 2), (1 / 8) ) + 20 x max((1 / 2),(1 / 8)) = 18 FPUs.
The total Consumption Units used by these functions and connectors are 18 FPUs x 1.8 Consumption Unit / CU-hour x 730 hours = 23652 Consumption Units.
Therefore, the total cost of these functions and connectors will be 23652 Consumption Units x $0.10 per Consumption Unit = $2365.20.