RisingWave Premium features

What are RisingWave premium features?

RisingWave offers a set of premium features for enterprise and mission-critical use cases. These features are built on top of the open-source RisingWave Community Edition and provide advanced capabilities to help users maximize the benefits of their RisingWave deployments. The Community Edition will continue to be freely available under the Apache License (Version 2.0), and we remain committed to supporting the needs of our open-source community and ecosystem. RisingWave’s core functionalities and a majority of its features are, and will always be, available in the Community Edition.

How to access premium features

Access to premium features depends on your RisingWave setup.

Self-managed deployments

For self-managed RisingWave clusters, you need to purchase a license key to unlock premium features. The RisingWave Community Edition and the binaries with premium features share the same underlying code. The license key simply unlocks the premium capabilities.

RisingWave Cloud

The availability of premium features in RisingWave Cloud depends on your subscription tier.

Pro Tier: All premium features are available out-of-the-box for users on the Pro tier.
Basic Tier: Users on the Basic tier have access to premium connectors without any additional charges. To access all other premium features, you will need to upgrade to the Pro tier.

Available premium features

Each row below is a premium feature. On RisingWave Cloud, all features in Connectors are included on both the Basic and Pro tiers; everything else requires the Pro tier. On self-managed deployments, every premium feature requires a license key.

Category	Feature	What it does
Tooling	RisingWave Console	Self-hosted operations console for managing multiple clusters, running `risectl`, automating snapshots, and collecting diagnostics.
Performance & cost	Elastic disk cache	Reduces S3 access costs by up to 90% with local-disk caching.
	State table memory preload	Preloads state tables into memory to accelerate stateful operators.
	Locality backfill	Preserves data locality across the pipeline for more efficient backfilling.
SQL & security	Time travel queries	Query historical states of tables and materialized views.
	Secret management	Securely store and reference connection credentials.
	Database isolation	Isolate workloads at the database level.
	Resource groups	Pin streaming jobs to dedicated compute resources.
Schema management	Auto schema change — PostgreSQL CDC	Apply upstream PostgreSQL schema changes automatically.
	Auto schema change — MySQL CDC	Apply upstream MySQL schema changes automatically.
	Auto schema change — Elasticsearch Sink	Propagate schema changes to Elasticsearch sinks.
	Auto schema change — Snowflake Sink	Propagate schema changes to Snowflake sinks.
	Auto schema change — Redshift Sink	Propagate schema changes to Redshift sinks.
	AWS Glue Schema Registry: Kafka source / Kafka sink	Use AWS Glue as the schema registry for Kafka.
Connectors	Sink to Snowflake	Stream data into Snowflake.
	Sink to DynamoDB	Stream data into DynamoDB.
	Sink to OpenSearch	Stream data into OpenSearch.
	Sink to BigQuery	Stream data into BigQuery.
	Sink to ClickHouse Cloud SharedMergeTree	Stream data into ClickHouse Cloud’s SharedMergeTree engine.
	Sink to SQL Server	Stream data into SQL Server.
	SQL Server CDC source	Ingest CDC streams directly from SQL Server.
	Glue catalog for Iceberg	Use AWS Glue as the Iceberg catalog.
	Redis Streams	Stream data into Redis Streams.

For users already on 1.9.x or earlier, the functionality of these features remains intact if you stay on that version. If you upgrade to v2.0 or later, an error will indicate that a license is required. The premium features are carefully selected based on the following criteria:

Seamless integration with proprietary or licensed open-source systems.
Advanced features that enhance development velocity and lower production deployment overhead.
Performance improvements for non-standard deployment environments.
Tailored features specifically requested by our paying customers.

Set up a license key

For self-managed deployments, you need to purchase and set up a license key to access premium features. The license key, essentially a certificate, is a JSON Web Token (JWT) that encodes information such as the license tier and expiration time. The integrity of the license key is validated using asymmetric encryption.

Free trial

RisingWave provides a trial of paid features for clusters with up to 4 RWUs (RisingWave Units), allowing you to evaluate these features on a small scale. With 4 RWUs, your cluster can use up to 4 CPU cores and 16 GiB of total memory. When the cluster exceeds either of these limits, the trial will be unavailable for both existing and future jobs, and you will need to acquire a license key to continue using the paid features.

For a fresh deployment, this free trial is included automatically.
For an existing deployment upgrading to this version, you may need to refresh the license key by executing ALTER SYSTEM SET license_key TO DEFAULT; in the SQL shell to activate the trial.

Set license key

Depending on the deployment, there are several different ways of setting license key.

RisingWave Operator (Kubernetes)
Helm (Kubernetes)
SQL
Local

If you used the RisingWave Operator to deploy the RisingWave, you could follow the steps to set the license key. For detailed instructions of deploying RisingWave with the RisingWave Operator, please check the Deploy RisingWave on Kubernetes with Operator.

Prepare a secret under the same namespace as the RisingWave object, e.g.,

apiVersion: v1
kind: Secret
metadata:
  name: risingwave-license
stringData:
  licenseKey: |
    <content of the license key>

Set the following fields of the RisingWave object.

apiVersion: risingwave.risingwavelabs.com/v1alpha1
kind: RisingWave
metadata:
  name: <your-risingwave>
spec:
  licenseKey:
    secretName: risingwave-license # the name of the secret above
    secretKey: licenseKey # the key in the secret above referencing the data of the license key

Apply the RisingWave object to Kubernetes.

The pod of the Meta Node (or standalone node) will restart to reflect the license key.If you’d like to renew the license key afterwards, you could simply update the content of the secret created above. The change will be propagated to and loaded by RisingWave automatically.

If you used the Helm chart to deploy the RisingWave, you could follow the steps to set the license key. For detailed instructions of deploying RisingWave with Helm, please check the Deploy RisingWave on Kubernetes with Helm.

Prepare a secret under the same namespace as the RisingWave Helm release, e.g.,

apiVersion: v1
kind: Secret
metadata:
  name: risingwave-license
stringData:
  licenseKey: |
    <content of the license key>

Set the following values, e.g., in the values.yaml file.

license:
  secret:
    name: "risingwave-license"
    key: "licenseKey"

Apply the values with the helm command-line tool.

# For fresh installation, you could provide additional values with more "-f <values.yaml>"
# For more information of the helm install, please refer to https://helm.sh/docs/helm/helm_install/
helm install -f values.yaml [-f <other-values.yaml>] <release-name> risingwavelabs/risingwave

# For upgrading existing one.
# For more information of the helm upgrade, please refer to https://helm.sh/docs/helm/helm_upgrade/
helm upgrade -f values.yaml --reuse-values <release-name> risingwavelabs/risingwave

The pod of the Meta Node (or standalone node) will restart afterwards to set the license key.If you’d like to renew the license key afterwards, you could simply update the content of the secret created above. The change will be propagated to and loaded by RisingWave automatically.

For an existing cluster, use this SQL command:

ALTER SYSTEM SET license_key TO '...';

Note you’ll need to rotate the license by yourself with the same SQL command before expiration.

There are several ways to set your license key to a local RisingWave:

Add system.license_key to your TOML configuration file before launching a new RisingWave
Set RW_LICENSE_KEY environment variable on Meta Node
Use the --license-key-path CLI option or the RW_LICENSE_KEY_PATH environment variable on Meta Node to specify a file holding the license key. Changes to the file will be monitored and Meta Node will reload the license key. This helps streamline license key rotation.

When the --license-key-path option or the RW_LICENSE_KEY_PATH environment variable is specified, any manual configuration of the license key through system parameters (license_key), the initial configuration (system.license_key), or the RW_LICENSE_KEY environment variable will be rejected.

Verify license key

To check if your license key is valid and test the availability of a specific feature, run:

SELECT rw_test_feature('feature_name');

Replace feature_name with the name of the feature you want to test. A result of t means the feature is available; an error message indicates the feature is not available based on your license.

rw_test_paid_tier() will be deprecated in a future release. Use rw_test_feature() instead.

View available features

To view all license-gated features and their availability, query the rw_features system table:

SELECT * FROM rw_features;

This returns a list of all features with their names, descriptions, and availability status based on your current license.

Retrieve license details

To retrieve detailed license information, run:

SELECT rw_license();

If the current license is valid, the output will look like this:

{"rwu_limit": null, "exp": 9999999999, "iss": "test.risingwave.com", "sub": "rw-test", "tier": "paid"}

Otherwise, an error message will indicate the issue (e.g., invalid token, expired license).

For rwu_limit, this specifies the number of RWUs (RisingWave Units) you can use for your cluster. Each RWU corresponds to 1 CPU core and 4 GiB of memory. With an rwu_limit of X, your cluster may use up to X CPU cores and up to (X * 4) GiB of total memory. Exceeding either limit will disable premium features. See RisingWave Unit (RWU) for more details.
For exp, this specifies the expiry time in Unix epoch seconds. You can use the to_timestamp function to convert the Unix epoch into a readable timestamp.

Premium support packages

RisingWave provides two levels of premium support packages:

Support package	Pro	Mission-Critical
Service Hours	24x7	24x7
Support Type	Premium	Premium
Support SLA	Urgent - 2 hrs	Urgent - 1 hr
	High - 8 hrs	High - 4 hrs
	Normal - 24 hrs	Normal - 12 hrs
	Low - 48 hrs	Low - 24 hrs
Designated Technical Account Manager	No	Yes
Slack / Team Channels	Yes	Yes

Pricing

A license for RisingWave premium features doesn’t include premium support. Customers can upgrade to the Pro or Mission-Critical support packages for an additional fee. For detailed pricing information on the premium features and support packages, please contact our sales team at sales@risingwave-labs.com.

Get started

Work with data

Install & Operate

Performance

Troubleshooting

Reference

Cloud

RisingWave Premium features

What are RisingWave premium features?

How to access premium features

Self-managed deployments

RisingWave Cloud

Available premium features

Set up a license key

Free trial

Set license key

Verify license key

View available features

Retrieve license details

Premium support packages

Pricing

​What are RisingWave premium features?

​How to access premium features

​Self-managed deployments

​RisingWave Cloud

​Available premium features

​Set up a license key

​Free trial

​Set license key

​Verify license key

​View available features

​Retrieve license details

​Premium support packages

​Pricing

What are RisingWave premium features?

How to access premium features

Self-managed deployments

RisingWave Cloud

Available premium features

Set up a license key

Free trial

Set license key

Verify license key

View available features

Retrieve license details

Premium support packages

Pricing