Google Patents a Smarter Way to Keep Database Indexes in Sync at Scale

By Patentlyze Team · Updated May 4, 2026

When a giant database splits its data across thousands of servers, keeping the indexes — the 'table of contents' that makes lookups fast — in sync with the actual data is surprisingly hard. Google's new patent describes a technique called cosharding that tries to keep index rows physically close to the data rows they point to.

What Google's cosharding trick actually does for big databases

Imagine a library where the card catalog is stored in a completely different building from the books. Every time you need a book, a librarian has to run across town to check the catalog, then run back to get the book. That's roughly the problem Google is solving here.

In a massive distributed database — think the kind that runs Google Cloud Spanner or similar services — data is split across thousands of machines. But the secondary indexes (the extra lookup tables that make searches fast) often end up on completely different machines than the data they index. That means every query involving an index requires extra network hops, slowing things down.

Google's patent describes cosharding: a method of slicing up those index tables using the same keys as the original data table, so that an index entry and the data row it points to land on the same physical server. Fewer network round-trips means faster queries.

How cosharding splits index rows by parent-table keys

The patent covers a method for organizing index tables in a distributed storage system so they're sharded — sliced into chunks called splits — in a way that mirrors how the original data table is sharded.

Here's the core mechanism:

• A data table arrives with rows, each containing two or more identifier keys (think primary key plus a foreign key or composite key) and the actual data payloads.
• For each piece of data in each row, the system creates a corresponding row in one of several index tables — standard secondary indexes that let you look up rows by non-primary-key columns.
• Critically, when those index tables are sharded (divided across servers), the split boundaries are chosen based on the same identifier key values from the original data table rows, not the index's own key ordering.

The result is that index rows end up colocated — physically stored on the same node or nearby nodes — as the data rows they reference. This is cosharding in practice: the index and the data 'co-inhabit' the same shard.

The patent also covers scenarios with multiple index tables stored on separate portions of the distributed system, each receiving its own cosharded splits, which means the technique scales across heterogeneous storage topologies.

What this means for distributed database query performance

For engineers building on top of distributed databases — whether that's Google Cloud Spanner, BigTable, or analogous systems — cross-shard index lookups are one of the biggest hidden latency costs. Every time a query uses a secondary index and the index lives on a different node than the data, you pay a network round-trip. At scale, that compounds fast.

Cosharding directly attacks that problem by making the index layout a function of the data layout. If Google ships this into a managed database product, you could get faster secondary-index queries without changing a single line of application code — the database engine just handles placement more intelligently. It's also relevant to Google's internal infrastructure, where Spanner-style globally distributed tables are core infrastructure.

Editorial commentary on a publicly published patent application. Not legal advice. Patentlyze may earn a commission if you click an affiliate link and make a purchase. This doesn't affect what we cover or how we cover it.