App profiles overview

An application profile, or app profile, stores settings that tell your Bigtable instance how to handle incoming requests from an application. When your application connects to a Bigtable instance, it uses either the default app profile or an app profile specified by you. Bigtable uses that app profile for requests that the application sends over that connection.

An app profile is either a standard app profile or a Data Boost app profile, depending on the type of compute it uses. A standard app profile uses provisioned cluster nodes for compute and is typically used for application-serving traffic. A Data Boost app profile uses serverless compute, which is designed for high-throughput read jobs and queries. For more information about Data Boost, read the Data Boost overview.

This page describes app profiles and provides guidance on using them.

For code samples showing how to use an app profile in your application, see Connect with a custom app profile.

Use a separate app profile for each workload

When you create a Bigtable instance, a default app profile is created automatically, and its settings depend on the number of clusters the instance has. To take full advantage of the benefits of app profiles, you should create and use additional app profiles and use a different app profile for each application or workload.

App profiles are especially important for instances that have two or more clusters, but even if your instance has only one cluster, you should use a unique app profile for each application that you run, or for different components within a single application.

The following sections describe the benefits of creating and using multiple app profiles.

Workload isolation

Using separate app profiles lets you use different Bigtable compute and routing policies for different purposes. For example, consider a situation when you want to prevent a batch read job (workload A) from increasing CPU usage on clusters that handle an application's steady reads and writes (workload B). You can take one of the following approaches:

  • Create a standard app profile for workload B that routes to a cluster group that excludes one cluster. Then you create a separate standard app profile for workload A that specifies single-cluster routing to the cluster that workload B doesn't send requests to.

  • Use a standard app profile, which uses cluster nodes for compute, configured to route to any cluster for workload B, and create a Data Boost app profile for use against a single cluster with workload A. Data Boost uses serverless compute, while the application traffic uses cluster nodes for compute.

You can change the settings for one application or function without affecting other applications that connect to the same data.

Observability

Using separate app profiles for different workloads gives you better insight into your applications' usage of Bigtable, because metrics are available per app profile. This increase in observability can be helpful in the following ways: