Stay organized with collections
Save and categorize content based on your preferences.
This page describes the features for search and secondary indexes.
When deciding between search indexes and secondary indexes, keep in mind that
search indexes should be the default choice for full-text use cases and
secondary indexes should be the default option for everything else. The
following table describes when to use each type of index.
Feature
Secondary index
Search index
Sort order
The index is sorted by all index key columns
Search index can only be sorted by at most two user-controlled INT64 columns
Arrays
You can't use arrays data type values as keys in secondary indexes.
Search indexes support array indexing. All tokens of a document are colocated in the same split. As a result, transactions that change 1 row only write to one index split.
JSON/JSONB
You can't use JSON values as keys in secondary indexes.
Search indexes support indexing JSON values.
Lookups
Lookup by index key only needs to access one split
Queries that use search index generally need to read from all splits of a given partition. The only exception is top-k pattern matching.
Multi-column indexing
Secondary indexes can include multiple key columns. Queries need to look up data by prefix of index key columns for efficient execution.
Search indexes can index multiple columns. Queries can specify complex logical expressions (conjunctions, disjunctions, negations) on any subset of the indexed columns, and still execute efficiently
Index intersection
Users can rewrite their query to join multiple secondary indexes.
Intersection of multiple indexed columns is implemented as an efficient local zig-zag join, followed by a distributed merge union (that combines results from all relevant splits).
Reading data
SQL Query or Read API
SQL Query
Besides semantics, the syntax of the DDL statement to create a search index is
different from the DDL syntax to create a secondary index:
Indexed columns are defined separately from the sort order in the
search index.
The order of TOKENLIST columns in the ON clause of the CREATE
SEARCH INDEX statement is immaterial.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-09-04 UTC."],[],[],null,["# Search versus secondary indexes\n\n| **Note:** This feature is available with the Spanner Enterprise edition and Enterprise Plus edition. For more information, see the [Spanner editions overview](/spanner/docs/editions-overview).\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nThis page describes the features for search and secondary indexes.\n\nWhen deciding between search indexes and secondary indexes, keep in mind that\nsearch indexes should be the default choice for full-text use cases and\nsecondary indexes should be the default option for everything else. The\nfollowing table describes when to use each type of index.\n\nBesides semantics, the syntax of the DDL statement to create a search index is\ndifferent from the DDL syntax to create a secondary index:\n\n- Indexed columns are defined separately from the sort order in the search index.\n- The order of `TOKENLIST` columns in the `ON` clause of the `CREATE\n SEARCH INDEX` statement is immaterial.\n\nWhat's next\n-----------\n\n- Learn about [search indexes](/spanner/docs/full-text-search/search-indexes).\n- Learn about [secondary indexes](/spanner/docs/secondary-indexes)."]]
