Class GoogleFirestoreAdminV1Index

Cloud Firestore indexes enable simple and complex queries against documents in a database. In Standard edition databases, single-field indexes are managed using the google.firestore.admin.v1.Field resource, and composite indexes are managed using the google.firestore.admin.v1.Index resource. In Enterprise edition databases, both single-field and composite indexes are managed using the google.firestore.admin.v1.Index resource.

Inheritance
object
GoogleFirestoreAdminV1Index
Implements
Inherited Members
Namespace: Google.Apis.Firestore.v1.Data
Assembly: Google.Apis.Firestore.v1.dll
Syntax
public class GoogleFirestoreAdminV1Index : IDirectResponseSchema

Properties

ApiScope

The API scope supported by this index.

Declaration
[JsonProperty("apiScope")]
public virtual string ApiScope { get; set; }
Property Value
Type Description
string

Density

Immutable. The density configuration of the index.

Declaration
[JsonProperty("density")]
public virtual string Density { get; set; }
Property Value
Type Description
string

ETag

The ETag of the item.

Declaration
public virtual string ETag { get; set; }
Property Value
Type Description
string

Fields

The fields supported by this index. At most 100 fields may be specified. In Standard edition databases only:

  • At least 2 fields must be specified. - The last field entry is always for the field path __name__. If, on creation, __name__ was not specified as the last field, it will be added automatically with the same direction as that of the last field defined. If the final field in the index is not directional, the __name__ will be ordered ASCENDING (unless explicitly specified).
Declaration
[JsonProperty("fields")]
public virtual IList<GoogleFirestoreAdminV1IndexField> Fields { get; set; }
Property Value
Type Description
IList<GoogleFirestoreAdminV1IndexField>

Multikey

Optional. Whether the index is multikey. By default, the index is not multikey. For non-multikey indexes, none of the paths in the index definition reach or traverse an array, except via an explicit array index. For multikey indexes, at most one of the paths in the index definition reach or traverse an array, except via an explicit array index. Violations will result in errors. Note this field only applies to index with MONGODB_COMPATIBLE_API ApiScope.

Declaration
[JsonProperty("multikey")]
public virtual bool? Multikey { get; set; }
Property Value
Type Description
bool?

Name

A server-defined name for this index. Output only. When used in the google.firestore.admin.v1.Index resource, the value is of the form: projects/{project_id}/databases/{database_id}/collectionGroups/{collection_id}/indexes/{index_id} When used in the google.firestore.admin.v1.Field resource, the value is empty.

Declaration
[JsonProperty("name")]
public virtual string Name { get; set; }
Property Value
Type Description
string

QueryScope

Indexes with a collection query scope specified allow queries against a collection that is the child of a specific document, specified at query time, and that has the same collection ID. Indexes with a collection group query scope specified allow queries against all collections descended from a specific document, specified at query time, and that have the same collection ID as this index.

Declaration
[JsonProperty("queryScope")]
public virtual string QueryScope { get; set; }
Property Value
Type Description
string

SearchIndexOptions

Optional. Options for search indexes that are at the index definition level. This field is only currently supported for indexes with MONGODB_COMPATIBLE_API ApiScope.

Declaration
[JsonProperty("searchIndexOptions")]
public virtual GoogleFirestoreAdminV1SearchIndexOptions SearchIndexOptions { get; set; }
Property Value
Type Description
GoogleFirestoreAdminV1SearchIndexOptions

ShardCount

Optional. The number of physical shards for the index. In Cloud Firestore, data and index entries are stored in contiguous, ordered key ranges called splits. While document keys within a collection are hashed to distribute write traffic across splits, secondary index entries are ordered lexicographically by their indexed field values. When an index contains fields with sequential or monotonically increasing or decreasing values (such as timestamps or auto-incrementing IDs), every incoming index write targets the boundary of the index keyspace on a single split. Because sequential writes continuously advance to the newest split at the edge of the range, automatic load-based splitting cannot divide the write traffic across storage servers. Under high write rates, this concentration creates an append hotspot on that single split, resulting in elevated write latency, contention errors, and transaction aborts. Sharded indexes solve this write bottleneck by hash partitioning the secondary index keyspace. When shard_count is configured to N, Firestore automatically prepends a virtual computed shard field (with values from 0 to N-1) as the leading field of the index. This splits a single sequential key range into N independent key ranges, uniformly scattering adjacent writes across distinct splits and storage servers to enable linear write scaling. Query trade-offs: Hash partitioning trades query performance for write throughput. Because matching index entries are scattered across all shards, queries executing against a sharded index cannot read from a single contiguous range. The query engine must fan out parallel seeks across all N shards and merge the ordered results. Even index point lookups and queries with LIMIT 1 must seek across all N shards. Sizing and best practices: - Indexes cannot be updated in-place. shard_count is immutable once an index is created; to "reshard" an index, create a new index with the desired shard_count and delete the original index. - Use sharded indexes only for indexes experiencing write bottlenecks (typically exceeding 500-1,000 writes/sec) on sequential or timestamp fields. - Do not shard indexes on uniformly distributed fields (such as UUIDs or hash tokens), where writes naturally spread across splits without sharding. Sharding uniform indexes adds query overhead without improving write throughput. - Do not shard read-heavy or low-write collections. - Size shard_count based on expected peak write throughput. Because a single split sustains roughly 500-1,000 writes/sec on sequential keys, estimate shard_count ≈ ceil(peak_write_qps / 500). - e.g., 4 for up to ~2,000-4,000 writes/sec, 16 for up to ~10,000+ writes/sec. - Setting an excessively high shard count produces diminishing write returns while needlessly increasing read latency and seek costs. If &lt;= 1, the index is unsharded (1 physical shard).

Declaration
[JsonProperty("shardCount")]
public virtual int? ShardCount { get; set; }
Property Value
Type Description
int?

State

Output only. The serving state of the index.

Declaration
[JsonProperty("state")]
public virtual string State { get; set; }
Property Value
Type Description
string

Unique

Optional. Whether it is an unique index. Unique index ensures all values for the indexed field(s) are unique across documents.

Declaration
[JsonProperty("unique")]
public virtual bool? Unique { get; set; }
Property Value
Type Description
bool?

Implements