A Bigtable app profile defines how Bigtable routes and handles incoming application requests. Every client connection to an instance uses an app profile, and that profile carries two decisions: which compute model serves the request, and how requests are distributed across the clusters in a replicated instance. The Professional Cloud Database Engineer exam tends to test the routing half of that, because the choice between routing modes is a direct trade among availability, latency, and cost, and the wrong answers in a scenario usually pick the mode that optimizes for the thing the question is not actually asking for.
Bigtable supports two kinds of app profile based on the compute model you want behind a workload. A standard app profile uses the provisioned cluster nodes to serve its workloads, which is the normal serving path for most applications. A Data Boost app profile uses serverless compute instead, and it exists for high-throughput reads and complex analytical queries that you want to run without consuming the capacity your provisioned clusters are using for primary traffic. The distinction matters when a workload is read-heavy or analytical and you do not want it competing with your main serving path.
When you create an instance, Bigtable creates a default app profile automatically, so an instance is usable immediately for basic setups. For production, the recommendation is to assign a unique app profile per application or per workload. Doing that lets you apply separate routing and compute policies to each one, and it improves observability, because each application shows up as a distinct entity rather than being collapsed into one shared label. If several applications all share a single profile, there is no way to distinguish their traffic types or prioritize one over another, which is the situation a per-workload profile is meant to avoid.
App profiles define the routing option that determines request distribution and failover behavior across the clusters in a replicated instance, and there are two of them. Single-cluster routing sends all requests to one specific cluster that you select within the instance. Because traffic is pinned to that one cluster, failover is manual. If the target cluster becomes unavailable, you have to intervene and point traffic at a different cluster yourself.
The reason to accept that is control. Single-cluster routing is the right choice when you need precise control over exactly where reads and writes land, and it avoids the high cross-region egress fees and the added latency that come from hitting distant clusters. By keeping traffic on one chosen location, you get predictable cost and consistent latency. The trade-off is lower availability than an automated setup, since recovering from a cluster outage depends on a manual step.
Multi-cluster routing routes each request to the nearest available cluster in the instance's region set. If a cluster becomes unavailable, it automatically fails over to another healthy cluster, which makes it the option for achieving high availability across regions with minimal manual intervention. There is no operator step in the failover path.
What you pay for that is on the cost and latency side. Multi-cluster routing incurs network egress charges, and latency can rise during a failover, because traffic may be rerouted to a more distant cluster in another region. So the profile of multi-cluster routing is higher availability at the price of higher cost and the possibility of higher latency during a failover event, which is close to the inverse of the single-cluster profile.
For the Professional Cloud Database Engineer exam, the useful way to hold this is by which factor a scenario is optimizing for. If the requirement is high availability with as little operational intervention as possible, multi-cluster routing fits, and you accept the egress cost and the failover latency that come with it. If the requirement is predictable cost, consistent low latency, or precise control over where data is served from, single-cluster routing fits, and you accept that failover is a manual operation. The two routing modes are configured on the app profile itself, so the answer to a routing question is almost always a property of the app profile rather than of the instance or the clusters in isolation. Keeping a separate app profile per workload is what makes it possible to give each application the routing mode its own availability and cost requirements call for.
Our Professional Cloud Database Engineer course covers Bigtable app profiles and routing alongside Bigtable replication and the broader availability and cost trade-offs across Google Cloud databases, with practice questions that drill these distinctions.
