Usage & billing
Materialize determines billing based on your compute and storage usage. Materialize bills per second based on the cluster(s) you provision for your workloads. Each cluster is a pool of resources (CPU, memory, and scratch disk space) that must stay up and running to continually provide you with always-fresh results.
Compute
In Materialize, clusters are pools of compute resources (CPU, memory, and scratch disk space) for running your workloads, such as maintaining up-to-date results while also providing strong consistency guarantees. The credit usage for a cluster is measured at a one second granularity.
quickstart cluster, you are You must provision at least one cluster to power your workloads. You can then use the cluster to create the objects (indexes and materialized views) that provide always-fresh results. In Materialize, both indexes and materialized views are incrementally maintained when Materialize ingests new data. That is, Materialize performs work on writes such that no work is performed when reading from these objects.
The cluster size for a workload will depend on the workload’s compute and
storage requirements. To help users select the correct cluster size for their
workload, Materialize uses cluster size names that are based on the compute
credit spend, specifically, “centicredits” or cc (1/100th of a compute credit). For
example, the 25cc cluster size is equivalent to 0.25 compute credits/hour; the
200cc cluster size is equivalent to 2 compute credits/hour. Larger clusters
can process data faster and handle larger data volumes.
Clusters are always “on”, and you can adjust the replication factor for fault tolerance. See Compute cost factors for more information on the cost of increasing a cluster’s replication factor.
Compute cost factors
The credit usage for a cluster is measured at a one second granularity. Factors that contribute to compute usage include:
| Cost factor | Details |
|---|---|
| Replication factor for a cluster. | Cost is calculated (at one second granularity) as cluster SIZE * REPLICATION FACTOR. |
| Indexes and materialized views | As data changes (insert/update/delete), indexes and materialized views perform incremental updates to provide up-to-date results. |
| Sources | • Sources that use upsert logic (i.e., ENVELOPE UPSERT or ENVELOPE DEBEZIUM Kafka sources) can lead to high memory and disk utilization.• Other sources consume a negligible amount of resources in steady state. |
SELECTs and SUBSCRIBEs |
• SELECTs and SUBSCRIBEs that do not use indexes and materialized views perform work. • SELECTs and SUBSCRIBEs that use indexes and materialized views are free. |
| Sinks | Only small CPU/memory costs. |
Storage
In Materialize, storage is roughly proportional to the size of your source datasets plus the size of any materialized views, with some overhead from uncompacted data and system metrics.
Materialize uses cheap, scalable object storage for its storage layer (Amazon S3), and primarily passes the cost through to the customer. At a rate of 0.0000411 USD per GB/hr, 1 TB stored for one month (730 hrs) equates to 30 USD.
Most data in Materialize is continually compacted, with the exception of append-only sources. As such, the total state stored in Materialize tends to grow at a rate that is more similar to OLTP databases than cloud data warehouses.
Invoices
From the Materialize console (Admin >
Usage & Billing), administrators can access their invoice. The invoice
provides Compute and Storage usage and cost information.