Skip to main content

Manage virtual compute pools

A virtual compute pool spins up when a query targets data outside the hot tier and spins down after reaching the maximum idle time you configure.

This topic explains how to create and manage virtual compute pools.

Prerequisites​

To create a virtual compute pool, you need a Lumi user with the Admin role. For information on roles and permissions, see Use roles to control access.

Create a virtual compute pool​

To query data outside the hot tier, you must first create a virtual compute pool. The first virtual compute pool you create becomes the default pool.

You can have up to 10 virtual compute pools per company account, each processing queries in isolation.

To create a virtual compute pool:

  1. From the Lumi navigation menu, click Virtual compute.
  2. Click + Create pool.
  3. In the Create virtual compute pool pane, enter the following:
    • Name: Pool name.
    • Description: Optional description of the pool.
    • Keys: IAM keys with the federated search integration that can route queries to this pool. If the IAM key doesn't exist yet, leave the Keys field blank and assign this pool when you create the key. For more information, see IAM key access.
    • Size: Compute resources allocated to virtual storage queries. For more information, see Size.
    • Idle time: Maximum time the virtual compute pool can remain idle before shutting down. Idle time must be between 15 minutes and 3 days.
  4. Click Create.

Once the pool is created, you can configure tiering rules to control when data moves out of the hot tier. For more information, see Manage tiering rules.

IAM key access​

When you create an IAM key for the federated search integration, you specify virtual tier access for the key. You can use the pre-selected default pool or choose a different pool if you have multiple pools configured. For information on how to create an IAM key, see Create an IAM key.

Application integrations that don't use federated search, such as Grafana, Tableau, or Model Context Protocol (MCP), always route queries to the default pool.

You can assign multiple IAM keys to a virtual compute pool, but a key can only have one pool.

To restrict virtual tier access, select No virtual tier access when configuring the IAM key. Keys without virtual tier access can only query data in the hot tier.

IAM key without virtual tier access

Size​

The size of a virtual compute pool is one of the factors that determine how much compute power is available to process queries. Other factors include the volume of data scanned, the shape of the data, and the complexity of the query.

Lumi measures the pool size in t-shirt sizes, such as Small, Medium, and Large. Each t-shirt size provides twice the compute, memory, and local storage of the previous size. Because each size runs on twice the infrastructure, it also costs twice as much.

The following table shows the default t-shirt sizes, their resources and cost relative to X-small, and their max concurrency:

SizeResources and costMax concurrency
X-small1x4
Small2x4
Medium4x4
Large8x8
X-large16x12
2X-large32x12
3X-large64x12

Max concurrency is the maximum number of queries a pool can run at the same time. It doesn't increase at every size, so two sizes with the same concurrency can still differ significantly in resources. For example, a Medium pool runs the same number of concurrent queries as an X-small pool, but has four times the resources to process each one.

Lumi Enterprise customers can define custom t-shirt sizes in Terraform. For more information, see Configure custom t-shirt sizes for Lumi Enterprise.

When selecting a t-shirt size, consider the following general guidelines:

  • Data size and composition: Larger and more complex datasets may require more compute resources to query.
  • Query latency: If low latency is required, you may need a larger t-shirt size for faster query execution and a longer idle time to avoid cold start delays.
  • Number of concurrent queries: If you regularly run more queries at the same time than your pool's max concurrency, choose a size with a higher max concurrency.

Idle time and cold starts​

A cold start is the delay before a query can run on the virtual tier. During a cold start, Lumi starts the virtual compute pool and loads the required data into virtual storage. A full cold start can take several minutes.

How much delay a query incurs depends on the status of the pool and the data:

  • Pool stopped, data not loaded: Lumi spins up the virtual compute pool and loads the data. This is a full cold start.
  • Pool running, data not loaded: Lumi loads the data, which adds some latency.
  • Pool running, data loaded: No additional latency. Performance is comparable to the hot tier.

The idle time setting controls how long the virtual compute pool can remain running without processing queries before it shuts down. After the pool shuts down, the next query triggers a new cold start.

When configuring the idle time for your virtual compute pool, consider the following:

  • A shorter idle time reduces costs, but leads to more cold starts.
  • A longer idle time keeps the pool available longer, but incurs more charges.

Status​

You can see the current status of your virtual compute pool on the Virtual compute page:

Virtual compute page

Because virtual compute resources spin up on demand and shut down after the idle time, the status of the virtual compute pool changes based on its current state:

  • Starting: Virtual compute pool is starting. Lumi is provisioning compute resources to serve queries.
  • Running: Virtual compute pool is running and available to serve queries.
  • Stopped: Virtual compute pool is inactive. All compute resources are shut down.

Modify a virtual compute pool​

To modify a virtual compute pool:

  1. From the Lumi navigation menu, click Virtual compute.
  2. Click the ellipsis next to the pool name.
  3. Select Edit or Delete.
    • If editing, make the necessary changes, then click Save.
    • If deleting, confirm your selection, then click Delete.
info

Updating IAM keys assigned to a virtual compute pool can take up to two minutes to take effect.

Learn more​

For more information, see the following topics: