Tiers & Storage
Choose a managed tier, compute size, storage type, and estimated throughput
Choose Free on shared infrastructure or a paid managed tier: Standard, Performance, or Enterprise. New paid deployments start with three dedicated nodes. Monthly pricing covers compute, storage, operations, and tier features. Data transfer is estimated separately and billed on actual usage.
Managed Tiers
| Tier | Starts from on AWS / month | Starts from on GCP / month | Default storage per node | Storage choices | Default availability | Telemetry |
|---|---|---|---|---|---|---|
| Standard | $199 | $199 | 100 GB Network Drive | Network Drive only | Single AZ | 14 days |
| Performance | $999 | $1,399 | 400 GB Local NVMe on AWS, 375 GB on GCP | Local NVMe or Network Drive | Single AZ | 30 days |
| Enterprise | $2,999 | $2,999 | 900 GB Local NVMe on AWS, 750 GB on GCP | Local NVMe or Network Drive | Multi AZ | 90 days |
Starting prices exclude transfer. They use us-east-1 on AWS and us-central1 on GCP. Catalog presets use 0.1 MB/s for Standard, 5 MB/s for Performance, and 10 MB/s for Enterprise. These inputs estimate traffic rather than reserve transfer. Larger compute or storage can increase monthly pricing. A smaller configuration cannot go below the tier's starting amount.
- Standard supports Network Drive only.
- Performance adds optional Local NVMe and VPC peering. Network Drive remains available.
- Enterprise adds Multi AZ, AWS PrivateLink, and GCP Private Service Connect. It requires an approved Enterprise or Custom account plan and direct contact. Business support, SLAs, and extra commercial features are agreed separately.
Every paid tier includes encryption in transit and at rest, provisioning, upgrades, and monitoring. Paid deployments have no broker throughput limit. See the pricing page, public pricing API, and billing guide.
The table describes catalog presets. If API creation omits storage, it uses 100 GB of Network Drive per node. If it omits availability, it uses Single AZ, including for Enterprise. Send the preset's compute, storage, and availability fields explicitly to match it. See Create a Managed Deployment.
Free
Free runs one isolated deployment slot on a shared host. Use it to learn the platform, develop applications, or run tests. The slot is not a dedicated virtual machine. The first eligible organization can run one Free deployment. Creating another organization does not grant another Free deployment.
The current default allocation is:
| Resource | Free allocation |
|---|---|
| Deployments | One for the first eligible organization |
| Nodes | One node on shared infrastructure |
| Memory | 512 MiB for the slot |
| Disk | 20 GiB quota on shared block storage |
| Network rate-limit value | 100 KB/s, or 800 kbit/s |
MiB and GiB are binary units. Console labels can use MB and GB for these values. Memory and disk figures describe the slot allowance, not the host total. The shared host applies the configured network ceiling to outgoing traffic.
General Iggy benchmark figures, such as messages per second or sub-millisecond latency, describe particular test workloads. They are not guarantees for a Free slot. Network distance also affects latency.
Its configuration includes these limits and defaults:
- Throughput is limited to 100 KB/s.
- Telemetry remains available for 7 days.
- The public IP can change after a restart. The deployment still receives a custom subdomain.
- A default access rule opens all Iggy protocols. You can restrict or replace it.
- Local NVMe, Multi AZ, and private connectivity are unavailable.
By default, the platform deletes a Free deployment after 14 days without traffic to release its slot. Warning emails arrive on days 10 and 12.
Region Availability
Choose from the regions offered for Free in the creation form. The list depends on the cloud and enabled regions, and allocation also needs free capacity in a shared host. A default selection such as us-west1 does not mean that every account must use that region. If the nearest region is unavailable, contact LaserData before relying on a distant region for latency-sensitive work.
Clusters
New paid managed deployments start with three dedicated nodes. A quorum is the number of replicas needed to agree on a write. For three nodes, that number is two. The cluster can keep serving after one node fails.
Single AZ puts the nodes in one availability zone. Multi AZ spreads the three-node configuration across three zones. See Server & Durability for write guarantees. The public extension endpoint does not currently add nodes. Use supported compute and storage upgrades instead.
Compute
Compute sets the size of each node. AWS offers Small through 8XLarge with Network Drive and Large through 16XLarge with Local NVMe. GCP offers Small through 8XLarge with Network Drive and Large through 8XLarge with Local NVMe. Published profiles define the supported storage and throughput for each size.
The deployment form and tiers discovery endpoint list sizes available to your account in the selected cloud and region. They also provide throughput guidance for sizing.
Partitions are dynamic, with no upfront count or per-partition charge. Storage needs depend on data volume, retention, and workload. Capacity metadata in the deployment preview describes storage assumptions, not a guaranteed partition limit.
Storage
Network Drive and Local NVMe both encrypt data at rest. Storage is provisioned and billed on all three nodes. Replicas protect the data but do not increase the capacity for unique messages.
Network Drive uses cloud block storage, such as EBS or Persistent Disk, rather than object storage. It supports 100 GB to 30,000 GB per node and can grow after creation. All paid managed tiers support it. Its API value is network_balanced.
Local NVMe attaches storage directly to the node. Capacity follows the Compute size. AWS starts Performance at 400 GB per node and Enterprise at 900 GB. GCP starts them at 375 GB and 750 GB. Larger Compute sizes provide more capacity. Local NVMe is available from Performance. Network Drive remains available on both Performance and Enterprise. Its API value is local_ssd.
Replication protects against node loss within the cluster's fault tolerance. Backups provide separate protection for supported storage types. Retention currently depends on provisioned disk capacity. Tiered object storage is planned, as described in Coming Soon.
Network
Throughput in MB/s is an input for estimating data transfer and selecting suitable compute. Self-service estimates range from 0.1 to 100 MB/s. Published compute and Local NVMe profiles impose additional sizing constraints.
The input does not reserve transfer or impose a paid broker limit. Measured transfer is billed using the network scope and availability mode. At a fixed resource configuration, a larger throughput estimate changes the estimated transfer amount without changing monthly pricing. If it requires larger compute, the additional capacity changes that configuration price.
Network scope describes where traffic travels:
| Scope | API value | Meaning |
|---|---|---|
| Same region | same_region | Traffic stays in the selected cloud region |
| Cross region | cross_region_same_cloud | Traffic crosses regions in the same cloud |
| Cross cloud or internet | cross_cloud | Traffic crosses a cloud boundary or the public internet |
Multi AZ adds a cross-zone transfer charge to the selected scope.
Telemetry Retention
Metrics, heartbeats, and logs share a retention period. Standard includes 14 days, Performance 30 days, and Enterprise 90 days. Free includes 7 days.
You can select a shorter period. The platform rejects a period above the tier's allowance. A tier-only upgrade applies the new retention directly. If an upgrade changes resources, the new retention takes effect after successful completion.
Upgrades
You can increase resources without recreating the deployment:
- Increase Compute to a larger size.
- Grow a Network Drive. Storage cannot shrink.
- Move to a higher tier, such as Standard to Performance or Performance to Enterprise.
A tier-only upgrade changes commercial terms and telemetry retention without changing hardware. Moving from Network Drive to Local NVMe requires a planned migration with LaserData. Local NVMe deployments cannot change Compute or Storage through self-service upgrades.
Upgrades require valid payment information. The can_upgrade field reports whether the cooldown permits an upgrade. Arrange tier downgrades with LaserData. See Upgrade a Deployment for the request.
Coming Soon
These features are planned and are not available:
- Serverless will provide dynamic streams and automatic scaling without a reserved dedicated cluster, through a lower-cost model shared by tenants.
- Tiered storage will move sealed segments to object storage such as S3. It will retain data beyond disk capacity, with Storage charges per GB-month.
- A Kafka gateway will let applications connect with their existing Kafka SDK or client.