Before Spanner makes sense, we need a few basic ideas.

A database is an organized memory

A database is a program whose job is to store information safely and give it back quickly when asked. Online shops keep their products and orders in one. Banks keep balances in one. Games keep player scores in one. The program must never lose data, and it must answer questions fast.

Relational databases and tables

A relational database stores information in tables, much like spreadsheets. A “customers” table has one row per customer, and an “orders” table has one row per order. Tables are linked by shared values, such as a customer number. You ask questions using a language called SQL. Relational databases have been trusted for decades because they follow strict rules that keep data correct.

ACID: the promise of correctness

The rules are often summarized by the word ACID. Atomic means a group of changes either all happen or none do. Consistent means the data always follows your rules. Isolated means two people changing data at the same time do not trip over each other. Durable means once the database says “saved,” the data survives crashes and power cuts.

The scaling problem

Traditional relational databases usually live on one main machine. When traffic grows, the usual fix is to buy a bigger machine, which has a limit and a high price. Another approach is to split data across many machines, but that is difficult and often forces you to give up some of those precious ACID guarantees. A different family of databases, often called NoSQL, scales across many machines easily but often relaxes consistency rules. Teams were forced to choose: grow big or stay correct.

A fully managed database that combines relational correctness with horizontal scale.

Cloud Spanner is Google Cloud’s fully managed, horizontally scalable relational database. It supports SQL, tables, indexes and full ACID transactions, yet it can spread data across many machines and, if you wish, across multiple regions of the world, without giving up strong consistency. Google describes the central promise simply: you get the familiar comfort of a relational database and the growth ability of a distributed one in a single service.

Spanner began inside Google, where it was built to run huge internal systems that could not tolerate lost or inconsistent data. Google published a famous research paper about it in 2012, and the cloud version became available to customers in 2017. That means the design has years of real, large-scale use behind it.

A short dictionary of Spanner words.

Many cooperating machines that look like one database from the outside.

Compute and storage are separated

Spanner separates the machines that do the work of running queries from the distributed file system that stores the bytes. This lets Spanner add or remove computing power without copying all your data around, and lets storage grow on its own. It is one reason scaling feels smooth.

Data is cut into splits

Spanner slices each table into contiguous ranges of rows, called splits, based on the primary key. A busy or growing split can be divided into two, and splits can be moved to less busy machines. This all happens automatically in the background. You never decide manually where a row lives.

Every split is replicated

Each split is copied to several replicas in different zones, and in multi-region setups, in different regions. The replicas use a consensus method called Paxos to agree on every change. One replica acts as a leader for the split and coordinates writes, while the others follow. If the leader fails, the group quickly elects a new one, usually without the application noticing.

flowchart TD
    APP[Your Application] --> CL[Spanner Client Library]
    CL --> FE[Spanner API Layer]
    FE --> S1[Split A: Leader]
    FE --> S2[Split B: Leader]
    subgraph Z1[Zone 1]
        S1
    end
    subgraph Z2[Zone 2]
        R1[Split A: Replica]
        S2
    end
    subgraph Z3[Zone 3]
        R2[Split A: Replica]
        R3[Split B: Replica]
    end
    S1 -.consensus.- R1
    S1 -.consensus.- R2
    S2 -.consensus.- R3
        

How machines on opposite sides of the planet agree on what happened first.

Ordering events is a hard problem in distributed systems. Two machines in different countries have clocks that drift apart by tiny amounts. If you cannot trust the clocks, you cannot be sure which of two changes happened first, and without that, strong consistency is out of reach.

Google solved this with TrueTime. Its data centers contain special time sources, namely GPS receivers and atomic clocks, which keep every machine’s clock very close to true time. Crucially, TrueTime does not pretend to be perfect. It reports time as a small window, saying “the true time is somewhere between this moment and that moment.” The window is usually only a few milliseconds wide.

When Spanner commits a change, it picks a timestamp and then briefly waits until it is certain that timestamp is truly in the past everywhere, a trick called commit wait. Because of this short pause, any transaction that starts after another has finished is guaranteed to see its effects. This gives what experts call external consistency, a very strong promise: the order the database presents is the same as the real-world order in which things happened.

The geography decision is the most important one you make when creating an instance.

Types of replicas

Not every copy plays the same role. Read-write replicas can vote and hold the leader role. Read-only replicas serve reads close to users but do not vote on writes. Witness replicas hold no data for reading, but they cast votes so the group can reach a majority. The exact mix depends on the configuration you choose.

How you tell Spanner how much power you need.

Spanner’s compute capacity is measured in nodes or, for finer control, processing units. One node equals 1,000 processing units, and you can begin with as few as 100 processing units, which is a tenth of a node. That makes it affordable to start small for a test or a modest application and grow later.

Capacity is what handles your queries. More capacity means more reads and writes per second and more room to run heavy queries. You can change capacity at any time without downtime and without moving your data by hand. Google also offers managed autoscaling that adds or removes capacity based on how busy the instance is, so you do not need to watch dashboards all day.

Good design is the biggest factor in whether Spanner feels fast and affordable.

Why primary keys matter so much

In a small database, the primary key is mostly a label. In Spanner, rows are stored in sorted key order, and splits are cut along that order. If your keys always increase, such as a number that counts upward or a timestamp, every new row lands at the very end of the table. That means one split receives all the writes while the others sit idle. This problem is called a hotspot, and it wastes the distributed power you are paying for.

The fix is to choose keys that spread writes out. Common approaches include random unique identifiers, adding a small shuffled prefix to the key, or using a sequence designed to be well-distributed. The goal is that new rows land all over the table rather than at one end.

Interleaved tables keep family together

Often, rows from one table naturally belong with rows from another, such as an order and its line items. Spanner lets you interleave a child table inside its parent so that related rows are stored physically next to each other. Reading an order together with all its items then touches one place instead of many, which makes queries faster and cheaper.

Other design tools

Secondary indexes let you search by columns other than the primary key. Foreign keys protect the links between tables. Schema changes can be made while the database stays online, and Spanner applies them in the background. As with any database, keep your design as simple as it can be, and avoid creating indexes you do not use, since each one costs storage and slows writes a little.

The different ways of reading and writing, and what each one costs.

The most important lesson is to match the tool to the job. If a page only displays a product list, a slightly stale read is perfectly fine and much faster for users far from the leader replica. If you are charging a customer, you want a full read-write transaction. Using the lightest option that is still correct keeps your application quick and your bill small.

sequenceDiagram
    participant App as Application
    participant Lead as Leader Replica
    participant Rep as Other Replicas
    App->>Lead: Begin read-write transaction
    Lead->>Lead: Lock the rows involved
    Lead->>Rep: Propose the change
    Rep-->>Lead: Majority agrees
    Lead->>Lead: Pick timestamp and commit wait
    Lead-->>App: Commit confirmed
        

You talk to Spanner in a language you probably already know.

Spanner supports SQL in two flavors, called dialects. The first is GoogleSQL, the same family of SQL used across many Google products. The second is a PostgreSQL interface, which lets teams who know PostgreSQL reuse a large portion of their skills, tools and drivers. You choose the dialect when you create a database, and it cannot be switched afterwards for that database, so decide early.

Over time Google has also added capabilities beyond plain tables, including change streams, which let other systems follow every change made to the data, full-text search, and support for graph-style and vector-style queries for modern applications. Because the product keeps evolving, check the current documentation to see which features are available in your chosen edition and dialect.

Choosing the right tool is half the battle.

What actually happens when a team adopts Spanner.

flowchart LR
    A[Requirements] --> B[Configuration and edition]
    B --> C[Schema design]
    C --> D[Create instance]
    D --> E[Load data]
    E --> F[Load test]
    F --> G[Go live]
    G -.-> C
        

Replication protects against hardware failure. Backups protect against everything else.

Because every change is copied to several zones or regions, Spanner already survives the loss of machines, zones and, in multi-region setups, whole regions without losing committed data. But replication also copies mistakes: if someone deletes the wrong rows, every replica faithfully deletes them too. For that reason you need separate recovery tools.

Layers of defense around your most valuable data.

Who may come in: identity and access

Access is controlled with Google Cloud’s identity and access management. You can grant people and applications narrow roles, such as permission to only read from one database. Spanner also offers fine-grained access control, which lets you limit access down to specific tables or columns for particular roles. The guiding rule is least privilege: give only the access that is truly needed.

Protecting data at rest and in transit

Data stored in Spanner is encrypted by default, and traffic is encrypted as it travels. If your rules require it, you can use your own encryption keys managed in Google Cloud’s key management service, which gives you control over when keys are rotated or disabled.

Keeping the perimeter tight

Network features such as private connectivity and service perimeters can limit how Spanner can be reached, reducing the chance of data leaving your trusted boundary. Audit logs record who did what, helping with investigations and compliance reviews.

Compliance

Google Cloud supports many industry standards and regional regulations, and data location choices in Spanner can help with residency rules. Compliance is shared work: the platform provides the controls, and you must configure and use them correctly.

flowchart TD
    A[Identity and IAM roles] --> B[Fine-grained access to tables and columns]
    B --> C[Private connectivity and service perimeters]
    C --> D[Encryption at rest and in transit]
    D --> E[Customer-managed keys optional]
    E --> F[Audit logs and monitoring]
        

Knowing what the database is feeling.

Spanner reports metrics to Google Cloud’s monitoring tools: processor utilization, request rates, latency, storage use and more. Built-in introspection features help you find the slowest queries, spot hotspots and see which parts of the data are under pressure. Query statistics and a query plan explorer show how a query is executed so you can improve it.

A pay-for-what-you-provision model with a few moving parts.

Spanner charges mainly for compute capacity, billed by the node or processing unit for each hour it exists, and for the amount of data stored. You also pay for backup storage and for network traffic that leaves a region in certain situations. Multi-region configurations cost more than regional ones because they hold more copies and use more resources. Different editions also have different prices. Because prices change, always use Google Cloud’s pricing page and calculator for current figures.

The kinds of problems Spanner was built for.

Honest strengths and honest limits.

Lessons from teams who have gone before you.

Best practices at a glance

Anti-patterns to avoid

It is a relational SQL database with the horizontal scaling that people usually associate with NoSQL systems. It supports tables, SQL and ACID transactions.

The CAP idea says that during a network split a distributed system must choose between consistency and availability. Spanner chooses consistency during such a split, but its careful engineering, private network and replication make real-world unavailability extremely rare, which is why it can still publish very high availability targets.

No. Spanner splits, moves and balances data automatically. Your job is to design good primary keys so the automatic process has something useful to work with.

Yes. Capacity can start at a fraction of a node and be increased at any time without downtime.

Choose regional if your users are concentrated in one area and a zone-level failure is your main concern. Choose multi-region when you need the highest availability, protection from a regional outage, or fast reads for users in several areas.

A hotspot is a small part of the data that receives most of the traffic, so one machine is overloaded while others are idle. It is usually caused by primary keys that increase in order.

Spanner offers a PostgreSQL interface that lets many PostgreSQL skills, drivers and tools be reused, although it is not a full copy of PostgreSQL, so check supported features before migrating.

Each split is stored on several replicas that agree on every change. If a machine or zone fails, a replica group elects a new leader and continues serving, usually with only a brief pause that client libraries handle through retries.

Yes, within limits. Spanner offers features that let analytical tools read data without disturbing your live application, and change streams can feed a data warehouse. For heavy reporting over very large datasets, a warehouse such as BigQuery is usually the better home.

Migration is very doable but needs planning, especially around primary keys, data types and any features that differ from your current database. Google provides migration tools and guidance, and testing with real data is essential.

Cloud Spanner brings together two things that were long thought to be incompatible: the strict correctness of a relational database and the unlimited growth of a distributed system. It does this through automatic splitting of data, replication with majority agreement, and TrueTime, Google’s globally synchronized clock. As a fully managed service, it removes much of the operational burden, but it still rewards good design, especially in primary keys and in the choice of read and transaction types. Use it where scale, availability and consistency truly matter, protect it with backups and security layers, watch its capacity and costs, and choose simpler tools when your needs are modest.