Manage multiple workloads efficiently in RisingWave using database isolation, resource groups for dedicated compute resources, and cross-database queries for unified access.
Running multiple distinct streaming applications, managing data for different teams, or separating environments (like development and staging) within a single RisingWave cluster offers significant operational advantages. However, it also presents challenges: ensuring stability by preventing interference between workloads, managing resource allocation effectively, and providing ways to access data across logical boundaries when necessary.
From v2.3, RisingWave provides a comprehensive suite of features to address these challenges, enabling robust workload isolation and flexible interaction:
PREMIUM EDITION FEATURE
Database isolation, resource groups, and cross-database queries are Premium Edition features. All Premium Edition features are available out of the box without additional cost on RisingWave Cloud. For self-hosted deployments, users need to purchase a license key to access this feature. To purchase a license key, please contact sales team at sales@risingwave-labs.com.
For a full list of Premium Edition features, see RisingWave Premium Edition.
This topic explains these capabilities and how they work together.
RisingWave incorporates foundational improvements that enhance the operational isolation between different databases within the same cluster, providing a more resilient environment out-of-the-box:
database_A
is significantly less likely to halt or affect the checkpoint process for unrelated jobs in database_B
, assuming no direct cross-database dependencies are created (e.g., via cross-database materialized views, see below).Benefits:
While database isolation improves logical and operational separation, databases might still share the same underlying pool of compute nodes (CNs) by default. This means they are not isolated from hardware failures affecting that shared pool or from resource contention (CPU, memory). For stronger infrastructure isolation and dedicated resource allocation, use Resource Groups.
Resource groups offer a powerful mechanism for fine-grained control over compute resource allocation and fault domains, essential for critical workloads, multi-tenant scenarios, and performance optimization.
A resource group is a named logical pool consisting of specific compute nodes (CNs) within your RisingWave cluster. Administrators typically define these groups and their associated CNs during cluster setup or configuration.
When you assign a database to a resource group, all streaming jobs belonging to that database are constrained to run only on the compute nodes within that designated group. This provides two primary advantages:
Granular fault isolation (limiting blast radius):
resource_group_A
crashes, it only impacts databases assigned to resource_group_A
. Databases in resource_group_B
(running on different CNs) remain unaffected by that specific hardware failure. This is crucial for ensuring the availability of critical applications.Workload matching & performance optimization:
rg_high_cpu
using CNs optimized for CPU and rg_high_memory
using CNs with large RAM. Assign CPU-intensive jobs (like complex pattern matching) to rg_high_cpu
and memory-intensive jobs (like large stateful aggregations) to rg_high_memory
for optimal performance and efficient resource utilization.1. Assigning a database to a resource group:
Use the WITH RESOURCE_GROUP
clause when creating a database using CREATE DATABASE
. The named resource group must exist beforehand.
If the WITH resource_group
clause is omitted, the database is typically assigned to a default resource group, potentially sharing resources more broadly with other databases not explicitly assigned elsewhere.
2. Monitoring resource group usage:
Use system catalogs to inspect resource group configuration and job assignments:
rw_resource_groups
: Lists defined groups and summarizes their assigned workers, parallelism, and the number of databases/jobs.
rw_streaming_jobs
: Shows active streaming jobs, including their database_id
and assigned resource_group
.
While isolating databases and resources using Resource Groups is crucial for stability and organization, you often need to query or join data residing in different databases. Cross-Database Queries allow you to do this directly within RisingWave (starting v2.3), avoiding cumbersome data duplication or external pipelines. This enables unified analytics even across isolated environments.
RisingWave’s cross-database functionality supports:
SELECT
statements.CREATE MATERIALIZED VIEW
) and Sinks (CREATE SINK
) that read from tables or MVs in other databases.CONNECT
, SELECT
, etc.) for secure access.To perform cross-database operations, users generally need:
CONNECT
privilege on the target (remote) database(s) they need to access.SELECT
or USAGE
) on the specific tables, views, or schemas being accessed in the remote database.superuser
bypasses these specific checks.SELECT
)You can query tables or views in another database using the standard three-part naming convention: database_name.schema_name.object_name
.
Interaction with Resource Groups: When you run an ad-hoc cross-database query, the compute resources used for executing that specific query are typically managed within the resource group associated with the database you are currently connected to.
CREATE MV
, CREATE SINK
) - Requires subscriptionsThe real power for continuous analysis comes from creating Materialized Views (MVs) or Sinks that process data across database boundaries. This allows you to maintain incrementally updated, unified views or data streams originating from different sources.
Critical requirement: CREATE SUBSCRIPTION
database_A
to react to ongoing changes in a table/MV from database_B
, it needs durable, cross-boundary access to the changelog of the source object in database_B
.CREATE SUBSCRIPTION
command makes this change stream persistently available across databases. Before creating an MV or Sink that reads from a table or MV in another database, you must first create at least one subscription for that specific upstream object in the source database. The upstream object must also have a primary key defined.CREATE MATERIALIZED VIEW
or CREATE SINK
operations.Example workflow:
In the source database (d1
), create a subscription for the upstream table (t1
):
In the target database (d2
), create the cross-database MV:
Creating a cross-database Materialized View or Sink introduces a dependency between the databases involved regarding checkpointing and job execution. Actors processing the MV/Sink might run within its database’s resource group while consuming data originating from another resource group’s source database via the subscription.
Additionally, RisingWave provides safeguards: DROP MATERIALIZED VIEW ... CASCADE
or DROP SINK ... CASCADE
operations are rejected if they have cross-database dependencies to prevent accidental data loss in the upstream database.
Leveraging database isolation, resource groups, and cross-database queries together enables several powerful patterns:
orders_db
, customers_db
) for clarity and independent scaling, then use cross-database MVs in an analytics_db
for holistic views.CREATE DATABASE
(includes WITH RESOURCE_GROUP
)rw_resource_groups
, rw_streaming_jobs
)