Multi-tenancy in Spanner: How many instances should I have?

When planning your Cloud Spanner deployment, one common question is, “How many Spanner instances should I create?” Let’s break down the factors involved in making this decision.

Understanding Spanner Instances

A Cloud Spanner instance is a fundamental building block. Here’s how Spanner’s hierarchy works: Project > Instance > Database > Table.

• Instances and Resources: Think of an instance as a container for databases. These databases share the instance’s processing units (PUs) and storage. For example, an instance with 3000 PUs and 6 databases means all databases share those resources. If one database consumes all the resources in an instance, others may experience slower performance.
• Instance Limits: You can have up to 100 databases per instance (with 1000 PUs, scaling proportionally for fewer PUs). There’s no limit to the number of instances in a project.
• Isolation: Resources are fully isolated between instances. This means if there are 6 instances, each with 1 database and 500PUs, then all databases will have their own dedicated resources, but no database can use over 500PUs.

Optimizing your Spanner configuration

Organizations often have numerous databases across various teams (We recommend that customers consolidate their data into as few databases as possible for optimal performance.). To determine the optimal number of instances, prioritize these goals:

1. Resource Utilization: Sharing instances can be more efficient, but there’s a risk of resource contention during peak usage.
2. Workload Isolation: Dedicated instances guarantee resources for specific applications but may be less efficient.
3. Operational Ease: Consolidating databases can simplify management, but excessive sharing can make scaling harder.

To find your ideal balance, start by ranking these goals. If resource utilization is paramount, shared instances might be suitable, especially with autoscaling to adapt to demand. However, if workload isolation is critical, dedicated instances are the way to go.

Tiered approach to instances

A helpful strategy is to categorize applications into tiers:

Tier 1: Mission-Critical Applications

• Downtime would be highly disruptive and potentially costly. These applications often warrant dedicated, multi-region instances to leverage Spanner’s robust 99.999% availability SLA.

Tier 2: Other Business Applications

• These are essential but not as critical as Tier 1. A few databases can share an instance, usually grouped by internal organizational structure. If different priority workloads share an instance, consider request priorities to ensure critical tasks are prioritized. For analytical workloads, use databoost to fully isolate read-only workloads

Tier 3: Development and Test Environments

• Prioritize operational ease by fitting as many databases as possible within an instance (up to the 100 database limit).

Important Consideration: Administrative Operations

Spanner limits administrative operations to 300 per minute per user per project. If you have 300 instances, this means you can only perform one operation per minute on each. Examples of admin operations include listing, creating, deleting, or resizing instances.

While 300 operations may seem ample, production environments often see multiple workloads peaking simultaneously. Plan your instance configuration to ensure you can scale effectively during high-traffic periods.