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-througput read jobs and queries. For more information on Data Boost (Preview), 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:

You're able to look at latency at the app profile level to help you determine which application might be impacting overall performance.
Monitoring the CPU utilization per app profile for a workload using a standard app profile can help you troubleshoot CPU utilization issues or make decisions about the size or location of the cluster, so you can optimize usage and reduce costs.
Metrics at the app profile level are useful if you need to seek support, because you're better able to share the exact workload that is causing an issue.

You can use the Bigtable Google Cloud console to view separate graphs of your Bigtable metrics for each app profile. To learn which metrics that are available at the profile level, see the table at Monitoring charts for Bigtable resources.

Standard app profiles

A standard app profile routes traffic to an instance's clusters using the clusters' nodes.

Routing

A standard app profile defines the routing policy that Bigtable uses and controls whether single-row transactions are allowed. A standard app profile also lets you specify the priority level for requests sent using the app profile.

Request priority

You can specify the priority that Bigtable should give to a standard app profile's data requests. To review the priority levels that are available, see Configure request priorities.

Data Boost app profiles

A Data Boost app profile lets you use Data Boost's serverless compute to isolate high-throughput jobs and queries from app serving traffic. A Data Boost app profile doesn't let you configure request priority, and the only routing policy available is single-cluster. For more information, see the Data Boost overview.

App profile changes

If you need to change the routing policy or request priority for a workload, you can update the app profile that is used for the workload. You can also convert an app profile from standard to Data Boost isolation or from Data Boost to standard isolation. Converting a standard app profile to use Data Boost removes the request priority settings from the app profile as well as any routing policies that aren't single-cluster.

Changes to an app profile are effective immediately.

However, in many cases, instead of modifying an app profile that is in use, you should create a new app profile with a different configuration, like you would for a new use case, and then change your application code to use the new app profile. Creating a new app profile to make changes for a workload ensures that you don't inadvertently change the app profile for any other workloads that use the app profile.

If you change an app profile from standard to Data Boost, the type of compute that is used for the app profile's traffic is changed to serverless, along with pricing. For more information, see the Data Boost overview and Bigtable pricing.

Similarly, if you change an app profile from Data Boost to standard, traffic that is sent by the app profile starts using cluster nodes for compute. This means that all clusters that the app profile routes to must have enough nodes to satisfy CPU usage requirements. For more information, see Nodes.

To see how to view, create, and update app profiles, see Create and configure app profiles.

Default app profile

When you create an instance, Bigtable automatically creates a default app profile for the instance. The default app profile is a standard app profile, but you can convert it to a Data Boost profile. If your application does not specify an app profile, or if you use the HBase shell to connect to your instance, Bigtable uses the settings in the default app profile.

The settings in an instance's default app profile depend on the number of clusters the instance had when you first created it:

If you created the instance with 1 cluster, the default app profile uses single-cluster routing, and it enables single-row transactions. This ensures that adding additional clusters later doesn't change the behavior of your existing applications.
If you created the instance with 2 or more clusters, the default app profile uses multi-cluster routing to any cluster. Single-row transactions are never allowed with multi-cluster routing.

The default app profile does not change when you add or remove clusters. You must manually update the default app profile to change its settings. However, as a best practice you should create and use a new app profile instead of changing the default app profile.

Custom app profiles

A custom app profile is an app profile that you create and configure. An instance can have up to 2,000 app profiles. Every app profile that is not the default is considered a custom app profile.