Indexing

Parent: Software Engineering · Published reference · snapshot 2026-08-31

An index is a data structure the database keeps sorted so it can find and order documents or rows without scanning the whole collection or table, at the cost of extra writes and storage. Compiled from 9 sources (MongoDB manual and docs, Prisma, Drizzle, Nile/Postgres, Turso/SQLite, Convex, InstantDB, MotherDuck): index types (B-tree, hash, GIN/GiST/SP-GiST/BRIN/bloom, compound, unique, partial, multikey, wildcard, text, geospatial, TTL, hidden, HNSW/IVFFlat), how the query planner chooses and uses an index (explain plans, IXSCAN vs COLLSCAN, covered queries, selectivity, the ESR guideline, hints), how ORMs declare indexes (@@index, index()/uniqueIndex(), .index()/withIndex), and the failure modes (unused or redundant indexes, write overhead, in-memory sorts, full scans).

These notes link each claim to its source. A source may be a research report hosted on this site rather than the primary document. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.

Definitions

Selectivity is a query property that describes the ratio of documents matching the query versus the total number of documents in a collection. The selectivity of an index describes how many documents a unique index key matches. A query or index has high selectivity when proportionally few documents match a query or a given index key. [source]
An index range is a description of which documents Convex should consider when running the query. [source]
GiST indexes are a versatile type of index that can handle complex data types, such as geometric shapes, full-text search, and network addresses. [They are implemented using a custom data structure optimized for searching large amounts of data1](https://www.postgresql.org/docs/current/gist.html). Here are some key points: [source]
SP-GiST (Spatial Generalized Search Tree) indexes are a versatile index type offered by PostgreSQL. They are designed for complex, non-rectangular data types and work especially well with geometrical and network-based data. Here are some key points: [source]
An expression index stores the result of an expression rather than a raw column value. Use expression indexes when queries frequently filter or sort by a computed value. [source]
Index prefixes are the beginning subsets of indexed fields. Compound indexes support queries on all fields included in the index prefix. [source]
The `where` argument allows you to define [partial indexes](https://www.postgresql.org/docs/current/indexes-partial.html) (also known as filtered indexes). A partial index only includes rows that match a specified condition, which reduces the index size and improves both write performance and query performance for the indexed subset of data. [source]
The SP-GiST index is a good choice for many different non-balanced data structures. If the query matches the partitioning rule, it can be very fast. [source]
Bounds intersection refers to the point where multiple bounds overlap. For example, given the bounds `[ [ 3, Infinity ] ]` and `[ [ -Infinity, 6 ] ]`, the intersection of the bounds results in `[ [ 3, 6 ] ]`. [source]
Rolling index builds are an alternative to [default index builds.](https://www.mongodb.com/docs/manual/core/index-creation/#std-label-index-operations) [source]
MongoDB Search Indexes are a specific type of index supported for search queries within Atlas. [source] — Atlas Search sense (Lucene), not a B-tree index
Indexes are a data structure that allow you to speed up your [document queries](/database/reading-data/.md#querying-documents) by telling Convex how to organize your documents. Indexes also allow you to change the order of documents in query results. [source]

Structure and components

Compound indexes may contain **a single** [hashed index field.](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-hashed/#std-label-index-type-hashed) [source]
1. **Plan Your Hierarchy**: Design your tree structure carefully before implementation 2. **Index Usage**: Create GiST indexes for better query performance: ```sql theme={null} CREATE INDEX path_idx ON categories USING GIST (path); ``` 3. **Validation**: Implement checks to maintain data integrity 4. **Path Length**: Keep paths reasonably short for better performance [source]
| Compound Index Components | Compound Index Behavior | |---|---| | Ascending indexes Descending indexes | Only indexes documents that contain a value for at least one of the keys. | | Ascending indexes Descending indexes [Geospatial indexes](https://www.mongodb.com/docs/manual/geospatial-queries/#std-label-index-feature-geospatial) | Only indexes a document when it contains a value for one of the `geospatial` fields. Does not index documents in the ascending or descending indexes. | | Ascending indexes Descending indexes [Text indexes](https://www.mongodb.com/docs/manual/core/indexes/index-ty [source]
1. **What is a GIN Index?** * A GIN index stores a set of `(key, posting list)` pairs. * The posting list contains row IDs where the key occurs. * Multiple posting lists can share the same row ID since an item can have multiple keys. * [Each key value is stored only once, making GIN indexes compact when the same key appears multiple times](https://www.postgresql.org/docs/current/gin-intro.html). 2. **Use Cases for GIN Indexes:** * GIN indexes are ideal for data values with multiple components, like arrays. * [They efficiently handle queries that search for specific component values within comp [source]
A `UNIQUE` index enforces that no two rows contain the same combination of values in the indexed columns. NULL values are considered distinct from each other, so a `UNIQUE` index permits multiple rows with NULL in the indexed columns. [source]
The order of the indexed fields impacts the effectiveness of a compound index. Compound indexes contain references to documents according to the order of the fields in the index. To create efficient compound indexes, follow the [ESR (Equality, Sort, Range) guideline.](https://www.mongodb.com/docs/manual/tutorial/equality-sort-range-guideline/#std-label-esr-indexing-guideline) [source]
Compound indexes can contain different types of sparse indexes. The combination of index types determines how the compound index matches documents. [source]
Only use wildcard indexes when the fields you want to index are unknown or may change. Wildcard indexes don't perform as well as targeted indexes on specific fields. If your collection contains arbitrary field names that prevent targeted indexes, consider remodeling your schema to have consistent field names. To learn more about targeted indexes, see [Create Indexes to Support Your Queries.](https://www.mongodb.com/docs/manual/data-modeling/schema-design-process/create-indexes/#std-label-create-indexes-to-support-queries) [source]
1. Create the `contacts` collection:db.contacts.insertMany( [ { name: "Evander Otylia", phone: "202-555-0193", address: [ 55.5, 42.3 ] }, { name: "Georgine Lestaw", phone: "714-555-0107", address: [ -74, 44.74 ] } ] ) The `address` field contains[legacy coordinate pairs.](https://www.mongodb.com/docs/manual/geospatial-queries/#std-label-geospatial-legacy) 2. To query for location data with the `$near` operator, you must create a[geospatial index](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-geospatial/#std-label-geospatial-index) on the field that contains the location da [source]
With the compound index on `department` and `description`, the query only examines **one** index key. There is only one document in the collection where `department` is `kitchen` and the `description` contains the string `green`. [source]
- Create a wildcard index that only covers specific fields. For example, if you have multiple embedded documents with multiple subfields, you can create an index to cover queries on both embedded documents and their subfields. - Create a wildcard index that omits specific fields. For example, if you have a collection that contains a field that is never queried, you can omit that field from the index. [source]
| Parameter | Type | Description | |---|---|---| | `keys` | document | A document that contains the field and value pairs where the field is the index key and the value describes the type of index for that field. For an ascending index on a field, specify a value of `1` . For descending index, specify a value of`-1` . An asterisk (`*` ) is not a valid index name. MongoDB supports several different index types, including: See [index types](https://www.mongodb.com/docs/manual/core/indexes/index-types/#std-label-index-types) for more information. [Wildcard indexes](https://www.mongodb.com/docs/ma [source]
| Parameter | Type | Description | |---|---|---| | `keyPatterns` | document | An array containing index specification documents. Each document contains field and value pairs where the field is the index key and the value describes the type of index for that field. For an ascending index on a field, specify a value of `1` ; for descending index, specify a value of`-1` . .. include:: /includes/indexes/wildcard-use-wc-methods.rst | | `options` | document | Optional. A document that contains a set of options that controls the creation of the indexes. See [Options](https://www.mongodb.com#std-label [source]
The [`dropIndexes`](https://www.mongodb.com#mongodb-dbcommand-dbcmd.dropIndexes) operation only kills queries that are using the index being dropped. This may include queries considering the index as part of [query planning.](https://www.mongodb.com/docs/manual/core/query-plans/#std-label-query-plans-query-optimization) [source]
However, if the query used a single-field text index only on the `description` field, the query would examine **three** index keys. There are three documents in the collection where the `description` field contains the string `green`. [source]
As part of the `JsonbPathOps` the `@>` operator is handled by the index, speeding up queries such as `value @> '{"foo": 2}'`. [source]
Optional filter expression made up of `q.or` and `q.eq` operating over the filter fields of the index. [source]
Indexes tell the database to create a lookup structure to make it really fast to filter data. If, in our chat app we wanted to build a way to look up `messages` from just one user, we'd tell Convex to index the `user` field in the `messages` table and write the query with the `withIndex` syntax. [source]
When creating HNSW, you can specify the maximum number of connections in a layer (`m`) and the number of candidate vectors considered when building the graph (`ef_construction`). More connections and more candidate vectors will improve recall but will increase build time and memory. If you don't specify the parameters, the default values are `m = 16` and `ef_construction = 64`. [source]
Database Manual - (manual) (Part 1 of 9) — > This part of the MongoDB manual covers getting started, administration, and core concepts like clustered collections, change streams, and geospatial and other index types. [source]
> This part of the MongoDB manual covers getting started, administration, and core concepts like clustered collections, change streams, and geospatial and other index types. [source]
The GIN index stores composite values, such as arrays or `JsonB` data. This is useful for speeding up querying whether one object is part of another object. It is commonly used for full-text searches. [source]
When you run `prisma db pull` on a database that contains partial indexes, Prisma ORM will: [source]
`on conflict do update` can have a `where` clause in two different places - as part of the conflict target (i.e. for partial indexes) or as part of the `update` clause: [source]
1. Create indexes on chemical structure columns: [source]
**1. Structure of B-Tree Indexes:** [source]
This is an object mapping each index name to the config for the index. [source]
This is an object mapping index names to index field paths. [source]
- Name of the cluster on which the rolling index build failed - Namespace on which the rolling index build failed - Project that contains the cluster and namespace - Organization that contains the project - Link to the [activity feed event](https://www.mongodb.com/docs/atlas/tutorial/activity-feed/#std-label-view-activity-feed) [source]
If your application repeatedly runs a query that contains multiple fields, you can create a compound index to improve performance for that query. For example, a grocery store manager often needs to look up inventory items by name and quantity to determine which items are low stock. You can create a compound index on both the `item` and `quantity` fields to improve query performance. [source]
A single compound index can contain up to 32 fields. [source]
The unique index allows the insertion of a document without the `email` field if the collection does not already contain a document missing the `email` field: [source]
When you create a geospatial index on a field that contains [legacy coordinate pairs](https://www.mongodb.com/docs/manual/reference/glossary/#std-term-legacy-coordinate-pairs), MongoDB computes [geohash](https://www.mongodb.com/docs/manual/reference/glossary/#std-term-geohash) values for the coordinate pairs within the specified [location range](https://www.mongodb.com/docs/manual/core/indexes/index-types/geospatial/2d/create/define-location-range/#std-label-2d-index-define-location-range), then indexes the geohash values. [source]
Because `test_scores` contains an array value, MongoDB stores this index as a multikey index. [source]
The `location` field is an embedded document that contains the embedded fields `city` and `state`. Create an index on the `location.state` field: [source]
This index supports single-field queries on any field in the collection. If a document contains an embedded document or array, the wildcard index traverses the document or array and stores the value for all fields in the document or array. [source]
The following operation creates a wildcard index that contains all scalar values (meaning strings and numbers) of the `attributes.size` and `attributes.color` fields: [source]
MongoDB can enforce a uniqueness constraint on a ranged shard key index. Using a unique index on the shard key enforces uniqueness on the entire key combination and not individual components of the shard key. [source]
An index covers a query when the index contains all of the fields scanned by the query. A covered query scans the index and not the collection, which improves query performance. [source]
(https://www.mongodb.com/docs/manual/core/transactions/) | | `ns` | document | The namespace (database and or collection) affected by the event. | | `ns.db` | string | The name of the database where the event occurred. | | `ns.coll` | string | The name of the collection where the event occurred. | | `operationDescription` | document | Additional information on the change operation. This document and its subfields only appears when the change stream uses [expanded events.](https://www.mongodb.com/docs/manual/reference/change-events/#std-label-change-streams-expanded-events) *New in version 6.0. [source]
- `listIndexes.cursor`- A result set returned in the batch size specified by your cursor. Each document in the batch output contains the following fields: FieldTypeDescriptionid integer A 64-bit integer. If zero, there are no more batches of information. If non-zero, a cursor ID, usable in a `getMore` command to get the next batch of index information.ns string The database and collection name in the following format: `<database-name>.<collection-name>`firstBatch document Index information includes the keys and options used to create the index. The index option hidden is only present if the va [source]
rd/#std-label-wildcard-index-core) | | `options` | document | Optional. A document that contains a set of options that controls the creation of the index. See [Options](https://www.mongodb.com#std-label-ensureIndex-options) for details. | | | integer or string | Optional. The minimum number of data-bearing voting replica set members (i.e. commit quorum), including the primary, that must report a successful [index build](https://www.mongodb.com/docs/manual/core/index-creation/#std-label-index-operations-replicated-build) before the primary marks the`indexes` as ready. A "voting" member is any r [source]
Test out your new index definition by inserting two users that do not contain the fields `accounts.bank` and `accounts.number`: [source]
The best way to filter in Convex is to use indexes. Indexes build a special internal structure in your database to speed up lookups. [source]
With vector indexes, the query will search a subset of the vectors that is expected to contain the nearest neighbors (but may not contain all of them). This is computationally efficient, but the results are not guaranteed to be the nearest neighbors. [source]
1. **Vectors**: A vector is a list of numbers that represents the essential characteristics of data. In AI, vectors are created using models that capture relationships between elements of the data. * **Example in NLP**: A sentence like "The cat sat on the mat" can be converted into a vector by a language model such as BERT or GPT. The vector might look something like `[0.34, 0.67, -0.23, 0.88, ...]`. This vector contains semantic information about the sentence. * **Example in Image Recognition**: An image of a car could be transformed into a vector that represents its visual features, such as [source]
Like [database indexes](/database/reading-data/indexes/.md), search indexes are a data structure that is built in advance to enable efficient querying. Search indexes are defined as part of your Convex [schema](/database/schemas.md). [source]
Like [database indexes](/database/reading-data/indexes/.md), vector indexes are a data structure that is built in advance to enable efficient querying. Vector indexes are defined as part of your Convex [schema](/database/schemas.md). [source]
Only documents that contain a vector of the size and in the field specified by a vector index will be included in the index and returned by the vector search. [source]
- To learn how to control the ranking of `$text` query results, see[Assign Weights to $text Query Results on Self-Managed Deployments.](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-text/control-text-search-results/#std-label-specify-weights) - You can include a wildcard text index as part of a compound text index. To learn more about compound text indexes, see [Create a Compound Text Index.](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-text/create-text-index/#std-label-compound-text-index-example) - To see examples of `$text` queries, see[`$text`.](h [source]
Text indexes are diacritic insensitive. The text index does not distinguish between characters that contain diacritical marks and their non-marked counterparts, such as `é`, `ê`, and `e`. More specifically, the text index strips the markings categorized as diacritics in the [Unicode 8.0 Character Database Prop List](http://www.unicode.org/Public/8.0.0/ucd/PropList.txt). [source]
| Parameter | Type | Description | |---|---|---| | `weights` | document | Optional. For [text](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-text/#std-label-index-type-text) indexes, a document that contains field and weight pairs. The weight is an integer ranging from 1 to 99,999 and denotes the significance of the field relative to the other indexed fields in terms of the score. You can specify weights for some or all the indexed fields. See[Assign Weights to $text Query Results on Self-Managed Deployments](https://www.mongodb.com/docs/manual/core/indexes/index-types/ind [source]
.mongodb.com/docs/manual/core/indexes/index-types/index-text/#std-label-index-type-text) indexes, the language that determines the list of stop words and the rules for the stemmer and tokenizer. See[$text Query Languages on Self-Managed Deployments](https://www.mongodb.com/docs/manual/reference/text-search-languages/#std-label-text-search-languages) for the available languages and[Specify Language for Text Indexes on Self-Managed MongoDB](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-text/specify-text-index-language/) for more information and examples. The default value is [source]
Each index that the Performance Advisor suggests contains the following metrics. These metrics apply specifically to queries which would be improved by the index: [source]
| Method | Availability | Description | |---|---|---| | View plan cache statistics | Atlas clusters and self-hosted deployments | The [`$planCacheStats`](https://www.mongodb.com/docs/manual/reference/operator/aggregation/planCacheStats/#mongodb-pipeline-pipe.-planCacheStats) aggregation stage returns information about a collection's[plan cache.](https://www.mongodb.com/docs/manual/core/query-plans/#std-label-query-plans-query-optimization) The plan cache contains query plans that the query planner uses to efficiently complete queries. Generally, the plan cache should contain entries for your m [source]
Query shapes identify similar queries by structure to help configure indexes and optimize performance for common patterns or block problematic ones. [source]
The schema is something else: the database's actual structure, the tables and indexes that exist right now. The contract lives in your repository; the schema lives in the database. Everything Prisma 8 does is a relationship between the two: queries are typed against the contract, migrations move the schema toward the contract, and verification checks that the schema still satisfies the contract. [source]
* New naming convention for constraints and indexes * Clear distinction between `map` (database-level name) and `name` (Prisma Client API name) * Primary and foreign key names are now part of the schema for supporting databases [source]
Everything on this page applies to both database families. On PostgreSQL, operations compile to SQL DDL and the applied state is tracked in a **marker**, a record Prisma 8 keeps in the database itself naming the contract state the database currently matches. On MongoDB, operations create collections, indexes, and JSON Schema validators, and the marker lives in a `_prisma_migrations` collection. The commands, the file layout, the graph, and the precheck/execute/postcheck structure are identical. [source]
* You have more source material than can fit in the generative model's context window. * You have a large number of questions that can be answered by the source material. So you can embed and index the source material once and then use it to answer many questions. * The source material is structured or can be chunked into smaller parts that are relevant to the questions. [source]
A bigram is a pair of consecutive characters in a string. For example, the word "hello" contains the following bigrams: "he", "el", "ll", "lo". pg\_bigm creates an index of these bigrams, enabling fast similarity searches and partial matching queries. [source]
**Tenant-aware Postgres pages**. A typical Postgres database comprises objects like tables and indexes, represented by 8KB pages. In Nile, tables are either tenant-specific or shared. Each page of a tenant table belongs exclusively to one tenant, with all records within a page associated with that tenant. This decoupled storage and tenant-dedicated page system allows for instantaneous tenant migration between different Postgres compute instances. Moving a tenant simply involves transferring tenant leadership from one compute instance to another while maintaining references to the same pages in [source]
The `stat` column contains space-separated integers. The first integer is the total number of rows in the table. Subsequent integers estimate the average number of rows that share the same value for the leftmost N columns of the index. [source]
This can be used to to model a queue, or to implement an `updatedAt` field. You could define an index on a field that captures the commit time, then use that to iterate over new or updated documents without worrying about missing changes due to out-of-order commits. For tips on using CommitTs for efficient iteration, see the notes in the [Batch Worker Component README](https://github.com/get-convex/batch-worker). [source]
A better option is to build an *index* on `author`. In the library, we could use an old-school [card catalog](https://en.wikipedia.org/wiki/Library_catalog) to organize the books by author. The idea here is that the librarian will write an index card for each book that contains: [source]
then Convex will create a new index called `by_author` on `author`. This means that your `books` table will now have an additional data structure that is sorted by the `author` field. [source]
One interesting detail to think about is the work needed to create this new structure. In the library, the librarian must go through every book on the shelf and put a new index card for each one in the card catalog sorted by author. Only after that can the librarian trust that the card catalog will give it correct results. [source]
For example, consider a query for `"item": "saccharomyces cerevisiae"` and `"stock": 60`. If the collection contains 10000 documents matching `"item": "saccharomyces cerevisiae"` and only 100 of those documents match `"stock": 60`, the query examines 10000 keys. In the `IXSCAN` stage, the query filters those keys by the `stock` field and only returns 100 results to the next stage. [source]
The index option `hidden` no longer appears as part of the `borough_1_ratings_1` index since the field is only returned if the value is `true`. [source]
The index contains a key for each individual value that appears in the `test_scores` field. The index is ascending, meaning the keys are stored in this order: `[ 62, 73, 88, 89, 92, 97 ]`. [source]
[Previous versions](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-text/text-index-versions/#std-label-text-index-versions) of the index treat `«` as part of the term `«était` and `»` as part of the term `monde»`. [source]
The `options` document contains a set of options that controls the creation of the index. Different index types can have additional options specific for that type. [source]
For each shard that contains chunks for the collection, follow the procedure to build the index on the shard. [source]
Once you finish building the index for a shard, repeat [C. Build Indexes on the Shards That Contain Collection Chunks](https://www.mongodb.com#std-label-tutorial-index-on-affected-shards) for the other affected shards. [source]
A sharded collection has an inconsistent index if the collection does not have the exact same indexes (including the index options) on each shard that contains chunks for the collection. Although inconsistent indexes should not occur during normal operations, inconsistent indexes can occur, such as: [source]
| Column | Description | | ------- | ------------------------------------------------ | | id | A unique identifier for this step | | parent | The id of the parent step (0 for top-level) | | notused | Reserved for future use (always 0) | | detail | Human-readable description of the execution step | [source]
If your schema has a composite type with a `@@unique` constraint, MongoDB prevents you from storing the same value for the constrained value in two or more of the records that contain this composite type. However, MongoDB does does not prevent you from storing multiple copies of the same field value in a single record. [source]

How it works

- `cursor.hint(index)`- ## Important**mongosh Method**This page documents a [`mongosh`](https://www.mongodb.com/docs/mongodb-shell/#mongodb-binary-bin.mongosh) method. This is*not* the documentation for a language-specific driver, such as Node.js.For MongoDB API drivers, refer to the language-specific [MongoDB driver documentation.](https://www.mongodb.com/docs/drivers/)Call this method on a query to override MongoDB's default index selection and [query optimization process](https://www.mongodb.com/docs/manual/core/query-plans/#std-label-read-operations-query-optimization) . Use[`db.collection [source]
- [`queryPlanner.winningPlan.queryPlan.inputStage.stage`](https://www.mongodb.com/docs/manual/reference/explain-results/#mongodb-data-explain.queryPlanner.winningPlan.queryPlan.inputStage) displays`IXSCAN` to indicate index use. - [`executionStats.nReturned`](https://www.mongodb.com/docs/manual/reference/explain-results/#mongodb-data-explain.executionStats.nReturned) displays`3` to indicate that the winning query plan returns three documents. - [`executionStats.totalKeysExamined`](https://www.mongodb.com/docs/manual/reference/explain-results/#mongodb-data-explain.executionStats.totalKeysExamin [source]
| Parameter | Type | Description | |---|---|---| | `unique` | boolean | Optional. Creates a unique index so that the collection will not accept insertion or update of documents where the index key value matches an existing value in the index. Specify `true` to create a unique index. The default value is`false` . The option is *unavailable* for[hashed indexes.](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-hashed/#std-label-index-hashed-index) | | `name` | string | Optional. The name of the index. If unspecified, MongoDB generates an index name by concatenating the names of [source]
* When the connection is in MVCC mode (`journal_mode=mvcc`). * On `WITHOUT ROWID` tables. * For custom index methods that have no backing B-tree, such as FTS and vector indexes. * When `PRAGMA query_only` is enabled. [source]
The fields `"ratings.scores.q1"` and `"ratings.scores.q2"` share the field path `"ratings.scores"`. In order to compound index bounds, a query must use `$elemMatch` on the common field path. [source]
- The Query Performance Summary shows the execution stats of the query: - Documents Returned displays `3` to indicate that the winning query plan returns three documents. - Index Keys Examined displays `3` to indicate that MongoDB scanned three index entries. The number of keys examined match the number of documents returned, meaning that the[`mongod`](https://www.mongodb.com/docs/manual/reference/program/mongod/#mongodb-binary-bin.mongod) only had to examine index keys to return the results. The[`mongod`](https://www.mongodb.com/docs/manual/reference/program/mongod/#mongodb-binary-bin.mongod) [source]
Because the constraint applies to separate documents, for a unique [multikey](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-multikey/#std-label-index-type-multikey) index, a document may have array elements that result in repeating index key values as long as the index key values for that document do not duplicate those of another document. In this case, the repeated index entry is inserted into the index only once. [source]
1. Use hstore when dealing with dynamic attributes that don't require strict schema validation. 2. Consider using JSON/JSONB instead if you need to store nested structures or arrays. 3. Create indexes on frequently queried keys using GiST or GIN indexes: [source]
`CREATE INDEX` builds an index on one or more columns or expressions of a table. Turso uses B-tree indexes in the same format as SQLite. The query planner automatically uses indexes when they can speed up a query -- you do not need to reference an index explicitly in your SQL statements. [source]
Because indexes can have different selectivities depending on the index keys used, ensure that the most selective indexes are available based on the predicates contained in a query. To ensure the most efficient query execution, create indexes that most uniquely match the predicates contained in a query. [source]
The [`.withIndex`](/api/interfaces/server.QueryInitializer.md#withindex) method defines which index to query and how Convex will use that index to select documents. The first argument is the name of the index and the second is an *index range expression*. An index range expression is a description of which documents Convex should consider when running the query. [source]
This query is invalid because the `by_channel` index is ordered by `(channel, _creationTime)` and this query range has a comparison on `_creationTime` without first restricting the range to a single `channel`. Because the index is sorted first by `channel` and then by `_creationTime`, it isn't a useful index for finding messages in all channels created 1-2 minutes ago. The TypeScript types within `withIndex` will guide you through this. [source]
If the index range is not specified, all documents in the index will be considered in the query. [source]
| Name | Type | Description [source]
1. **Infrastructure**: SP-GiST indexes support various kinds of searches, similar to GiST indexes. [They permit the implementation of a wide range of different non-balanced disk-based data structures, such as quadtrees, k-d trees, and radix trees (tries) 1](https://www.postgresql.org/docs/current/spgist.html). 2. **Use Cases**: * **Geometric Searches**: SP-GiST is ideal for spatial data, such as points, lines, and polygons. * **IP Network Searches**: When dealing with IP addresses or network ranges. * [**Text Search with Complex Pattern Matching**: For scenarios where you need to search for pa [source]
Remember that BRIN indexes are most effective when dealing with large tables and specific column types. [source]
A composite index is useful when queries filter or sort by multiple columns. The order of columns matters -- an index on `(a, b)` can accelerate queries filtering on `a` alone, but not queries filtering only on `b`. [source]
**Index bounds** define the range of index values that MongoDB searches when using an index to fulfill a query. When you specify multiple query predicates on an indexed field, MongoDB attempts to combine the bounds for those predicates to produce an index scan with smaller bounds. Smaller index bounds result in faster queries and reduced resource use. [source]
When a single unqualified name is given, Turso resolves it in the order **collation → table → index**: if the name matches a collation sequence, all indexes using that collation are rebuilt; otherwise it is treated as a table or index name. [source]
The `prisma` relation mode does not use foreign keys, so no indexes are created when you use Prisma Migrate or `db push` to apply changes to your database. You instead need to manually add an index on your relation scalar fields with the [`@@index`](https://www.prisma.io/docs/orm/v7/reference/prisma-schema-reference#index) attribute (or the [`@unique`](https://www.prisma.io/docs/orm/v7/reference/prisma-schema-reference#unique), [`@@unique`](https://www.prisma.io/docs/orm/v7/reference/prisma-schema-reference) or [`@@id`](https://www.prisma.io/docs/orm/v7/reference/prisma-schema-reference) attri [source]
The Convex TypeScript types in the `withIndex` make this clear because they require that you compare index fields in order. Because the index is defined on `["author", "title"]`, you must first compare the `author` with `.eq` before the `title`. [source]
The [btree\_gin](https://www.postgresql.org/docs/current/btree-gin.html) extension in PostgreSQL enables GIN indexes to support B-tree indexable data types. It is useful when you want to use a GIN index for multi-column queries that include standard B-tree searchable data types like `int`, `text`, `timestamp`, and `uuid`. Your Nile database arrives with `btree_gin` extension already enabled, so there's no need to run `create extension`. [source]
A GIN index with `btree_gin` is useful when performing multi-column searches that include B-tree indexable columns. Here's how to create one: [source]
- To utilize an index on an embedded document, your query must specify the entire embedded document. This can lead to unexpected behaviors if your schema model changes and you add or remove fields from your indexed document. - When you query embedded documents, the order that you specify fields in the query matters. The embedded documents in your query and returned document must match exactly. To see examples of queries on embedded documents, see [Query on Embedded/Nested Documents.](https://www.mongodb.com/docs/manual/tutorial/query-embedded-documents/#std-label-read-operations-subdocuments) [source]
- To use the `wildcardProjection` option, your index key must be`$**` . - Wildcard indexes don't support mixing inclusion and exclusion statements in the `wildcardProjection` document except when explicitly including the`_id` field. For example: - The following `wildcardProjection` document is**invalid** because it specifies both an inclusion and an exclusion of a field:{ "wildcardProjection" : { "attributes" : 0, "users" : 1 } } - The following `wildcardProjection` document is**valid** because even though it specifies both inclusion and exclusion, it includes the`_id` field:{ "wildcardProject [source]
For a compound index where the index prefix keys are not strings, arrays, and embedded documents, an operation that specifies a different collation can still use the index to support comparisons on the index prefix keys. [source]
Wildcard indexes do not support mixing inclusion and exclusion statements in the `wildcardProjection` document *except* when explicitly including the `_id` field. For more information on `wildcardProjection`, see the [parameter documentation](https://www.mongodb.com/docs/manual/reference/method/db.collection.createIndexes/#std-label-createIndexes-method-wildcard-option). [source]
- [`$regex`](https://www.mongodb.com/docs/manual/reference/operator/query/regex/#mongodb-query-op.-regex) is a range operator. - When `$in` is used alone, it is an equality operator that performs a series of equality matches. - When `$in` is used with`.sort()` : - If `$in` has fewer than 201 array elements, the elements are expanded and then merged in the sort order specified for the index using a`SORT_MERGE` stage. This improves performance for small arrays. In this case,`$in` is similar to an equality predicate with ESR. - If `$in` has 201 elements or more, the elements are ordered like a ra [source]
When you create an index, you can give the index a custom name. Giving your index a name helps distinguish different indexes on your collection. For example, you can more easily identify the indexes used by a query in the query plan's [explain results](https://www.mongodb.com/docs/manual/reference/explain-results/#std-label-explain-results) if your indexes have distinct names. [source]
- If `totalDocsExamined` has a value much greater than that of`nReturned` , it indicates an ineffective index. That is, MongoDB had to scan the collection in order to filter the results.[Create an index](https://www.mongodb.com/docs/manual/core/indexes/create-index/#std-label-manual-create-an-index) on the filter fields to improve performance. - If `totalDocsExamined` and`nReturned` have the same values, it indicates that MongoDB only examined the documents that it returned. This indicates an effective index. [source]
The `USE INDEX` hint suggests to the optimizer which indexes to consider when processing the query. The optimizer is not forced to use these indexes but will prioritize them if they are suitable. [source]
The ANALYZE statement collects statistics about the contents of tables and indexes. The query optimizer uses these statistics to choose better query plans, particularly when deciding which index to use and how to order joins. [source]
The ANALYZE statement gathers statistics about the distribution of values in indexes and stores the results in the `sqlite_stat1` table (and optionally `sqlite_stat4`). The query optimizer reads these statistics to make better decisions about: [source]
It is recommended to add indexes on the columns used for filtering, so the query can be optimized. Especially when the use of the filter can lead to small enough result sets that a sequential scan is faster than use of the vector index. This will optimize not just performance but also recall. [source]
* [**Creating and Altering Tables**](postgres/createtable): Tables are the basic building block of a relational database. Tables (sometimes referred to as relations or tuples) are used to store data in rows and columns. We will cover how to create tables, add columns and define constraints such as primary keys and foreign keys. * [**Data Types**](postgres/datatype/): Postgres supports a wide range of data types for storing different types of data. In a table, each column has a data type, and based on this data type, Postgres allocates storage and allows various operations. We will cover some o [source]
In this example, the range expression is omitted because we're looking for the highest scoring players of all time. This particular query is reasonably efficient for large data sets only because we're using `take()`. [source]
When introspecting a database, the `map` argument will *only* be rendered in the schema if the name *differs* from Prisma ORM's [default constraint naming convention for indexes and constraints](#prisma-orms-default-naming-conventions-for-indexes-and-constraints). [source]
Prisma ORM naming convention was chosen to align with PostgreSQL since it is deterministic. It also helps to maximize the amount of times where names do not need to be rendered because many databases out there they already align with the convention. [source]
Prisma ORM always uses the database names of entities when generating the default index and constraint names. If a model is remapped to a different name in the data model via `@@map` or `@map`, the default name generation will still take the name of the *table* in the database as input. The same is true for fields and *columns*. [source]
When no explicit names are provided via `map` arguments Prisma ORM will generate index and constraint names following the [default naming convention](#prisma-orms-default-naming-conventions-for-indexes-and-constraints). [source]
If you introspect a database the names for indexes and constraints will be added to your schema unless they follow Prisma ORM's naming convention. If they do, the names are not rendered to keep the schema more readable. When you migrate such a schema Prisma will infer the default names and persist them in the database. [source]
* B-trees are versatile and widely applicable: * **Equality and Range Queries**: They excel in handling equality and range queries. Common operators include `=`, `<`, `>`, `BETWEEN`, and `IN`. * **NULL Conditions**: B-trees can handle `IS NULL` or `IS NOT NULL` conditions. * **Pattern Matching**: When anchored to the beginning of a string, they efficiently support pattern matching using `LIKE` or `~`. [source]
Starting in version `0.8.0`, you can enable **iterative index scans**, which will automatically scan more of the index when needed. [source]
Even with iterative scans, pgvector limits the index scan in order to balance time, resource use and recall. Increasing these limits can increase query latency but potentially improve recall: [source]
FTS indexes are updated automatically when you modify the underlying table. [source]
> [!NOTE] > Note the `@@index([authorId])` on the `Post` model for MySQL. PlanetScale MySQL requires indexes on foreign keys when using `relationMode = "prisma"`. [source]
Given all of this, we can conclude that **the performance of indexed queries is based on how many documents are in the index range**. In this case, the performance is based on the number of Isaac Asimov books because the librarian will need to look at each one to examine its title. [source]
1. Create the index **after** the table has some data 2. Choose an appropriate number of lists - a good place to start is `rows / 1000` for up to 1M rows and `sqrt(rows)` for over 1M rows. 3. When querying, specify an appropriate number of probes (higher is better for recall, lower is better for speed) - a good place to start is `sqrt(lists)` [source]
LibSQL implements [DiskANN](https://turso.tech/blog/approximate-nearest-neighbor-search-with-diskann-in-libsql) algorithm in order to speed up approximate nearest neighbors queries for tables with vector columns. [source]
This query is a *full table scan* because it requires Convex to look at every document in the table. The performance of this query is based on the number of books in the library. [source]
One option is to re-sort the entire library by `author`. This will solve our immediate problem but now our original queries for `firstBook` and `lastBook` would become full table scans because we'd need to examine every book to see which was inserted first/last. [source]
The `createIndexes` event in change streams occurs when an index is created with expanded events enabled. [source]
* **Same database.** Your Prisma 8 config points at the **same** database and connection string as v6. * **Server version.** Your MongoDB server is on 8.0 or newer. * **Dry run first.** Rehearse the whole flow on a throwaway copy of your database (`contract emit`, `db update --dry-run`, `db update`, `db verify`) and make sure `db verify` passes before you touch production. * **Index parity.** The indexes on each collection (`db.collection.getIndexes()`) match your contract. * **Validators.** Your existing documents pass the strict validators Prisma 8 adds to each collection (see *Good to know* [source]
Previous versions of Prisma ORM used to create a *unique index* on these two columns. In Prisma v6, this unique index is changing to a *primary key* in order to [simplify for the default replica identity behaviour](https://github.com/prisma/orm/issues/25196). [source]
In MySQL, the default collation setting for string comparison is case-insensitive, which means that when performing operations like searching or comparing strings in SQL queries, the case of the characters does not affect the results. However, because collation settings can vary and may be configured to be case-sensitive, we will explicitly ensure that the `email` is unique regardless of case by creating a unique index on the lowercased `email` column. [source]
- Indexes on individual foreign key columns (`userId`, `groupId` in `usersToGroups`) help when you are querying from one side to find the other (e.g., "find groups for a user"). - The composite index on `(userId, groupId)` in `usersToGroups` is particularly important for quickly finding all relationships defined in the junction table. This is used when Drizzle ORM resolves the `many-to-many` relation to fetch related entities. </Callout> [source]
* Indexes that reference the column (including expression indexes) * Triggers that reference the column * CHECK constraints that reference the column * Foreign key constraint definitions [source]
Building an index in a rolling fashion reduces the resiliency of your cluster and increases index build times. We only recommend using rolling index builds when regular index builds do not meet your needs. [source]
When an index build completes, Atlas generates an [activity feed event](https://www.mongodb.com/docs/atlas/tutorial/activity-feed/#std-label-view-activity-feed) and sends a notification email to the project owner with the following information: [source]
- The values in the field you query with the `$geoWithin` operator must be in GeoJSON format. - When you specify longitude and latitude coordinates, list the **longitude** first, and then**latitude** . - Valid longitude values are between `-180` and`180` , both inclusive. - Valid latitude values are between `-90` and`90` , both inclusive. - When you specify Polygon `coordinates` , the first and last coordinates in the array must be the same. This closes the bounds of the polygon. - `$geoWithin` does not require a geospatial index. However, a geospatial index improves query performance. Only th [source]
- When you specify longitude and latitude coordinates, list the **longitude** first, and then**latitude** . - Valid longitude values are between `-180` and`180` , both inclusive. - Valid latitude values are between `-90` and`90` , both inclusive. - A location intersects with an object if it shares at least one point with the specified object. This includes objects that have a shared edge. - `$geoIntersects` does not require a geospatial index. However, a geospatial index improves query performance. Only the[2dsphere](https://www.mongodb.com/docs/manual/core/indexes/index-types/geospatial/2dsph [source]
Compound bounds combine bounds for multiple keys of a [compound index](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-compound/#std-label-index-type-compound). Using bounds from multiple keys reduces the time it takes to process a query because MongoDB does not need to compute results for each bound individually. [source]
If a field is an embedded document or array (like `attributes.size`), the wildcard index recurses into the field and indexes all embedded scalar field values. [source]
For more information on creating indexes that support your workload, see [Create Indexes to Support Your Queries.](https://www.mongodb.com/docs/manual/data-modeling/schema-design-process/create-indexes/#std-label-create-indexes-to-support-queries) [source]
Unfortunately, it is expensive to create a lot of individual indexes to cover all of the possible queries. A wildcard index is a good alternative to creating a large number of individual indexes because one wildcard index can efficiently cover many potential queries. [source]
- If the field is an object, the wildcard index descends into the object and indexes its contents. The wildcard index continues descending into any additional embedded documents it encounters. - If the field is an array, the wildcard index traverses the array and indexes each element: - If the element is an object, the wildcard index descends into the object to index its contents. - If the element is an array (that is, an array which is embedded directly within the parent array), the wildcard index does not traverse the embedded array, but indexes the *entire* array as a single value. - For al [source]
When a wildcard index encounters an array, it traverses the array to index its elements. If the array element is itself an array (an embedded array), the index records the *entire* embedded array as a value instead of traversing its contents. [source]
The index records for `ship.coordinates` and `ship.captains` do not include the array position for each element. Wildcard indexes ignore array element positions when recording the element into the index. However, wildcard indexes can still support queries that include explicit array indices. [source]
Collation-aware index keys might be larger than index keys for indexes without collation because indexes that are configured with collation use ICU collation keys to achieve sort order. [source]
- `dropIndexes`- *New in version 6.0.* :A `dropIndexes` event occurs when an index is dropped from the collection and the change stream has the[showExpandedEvents](https://www.mongodb.com/docs/manual/reference/change-events/#std-label-change-streams-expanded-events) option set to`true` . [source]
For replica sets, run [`dropIndexes`](https://www.mongodb.com#mongodb-dbcommand-dbcmd.dropIndexes) on the [primary](https://www.mongodb.com/docs/manual/reference/glossary/#std-term-primary). The primary stops the index build and creates an associated "abortIndexBuild" [oplog](https://www.mongodb.com/docs/manual/reference/glossary/#std-term-oplog) entry. Secondaries which replicate the "abortIndexBuild" oplog entry stop the in-progress index build and discard the build job. See [Index Build Process](https://www.mongodb.com/docs/manual/core/index-creation/#std-label-index-build-process) for deta [source]
- `cursor.min()`- ## Important**mongosh Method**This page documents a [`mongosh`](https://www.mongodb.com/docs/mongodb-shell/#mongodb-binary-bin.mongosh) method. This is*not* the documentation for a language-specific driver, such as Node.js.For MongoDB API drivers, refer to the language-specific [MongoDB driver documentation.](https://www.mongodb.com/docs/drivers/)Specifies the *inclusive* lower bound for a specific index in order to constrain the results of[`find()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.find/#mongodb-method-db.collection.find) .[`min()`](https:// [source]
If a field is a nested document or array, the wildcard index recurses into it and indexes all scalar fields in the document or array. [source]
If a field is a nested document or array, the wildcard index recurses into the document or array and indexes all scalar fields in the document or array. [source]
The [primary](https://www.mongodb.com/docs/manual/reference/glossary/#std-term-primary) marks index build as ready only after a simple majority of data-bearing voting members "vote" to commit the index build. For more information on index builds and the voting process, see [Index Builds in Replicated Environments.](https://www.mongodb.com/docs/manual/core/index-creation/#std-label-index-operations-replicated-build) [source]
When you specify options to [`db.collection.createIndexes()`](https://www.mongodb.com#mongodb-method-db.collection.createIndexes), the options apply to *all* of the specified indexes. For example, if you specify a collation option, all of the created indexes will include that collation. [source]
Leaving the index name field blank causes MongoDB Compass to create a default name for the index. [source]
When run with an index, the query scanned `3` index entries and `3` documents to return `3` matching documents, resulting in a very efficient query. [source]
When the index build completes, shutdown the [`mongod`](https://www.mongodb.com/docs/manual/reference/program/mongod/#mongodb-binary-bin.mongod) instance. To return the node to its original configuration, undo the configuration changes that you made when you started the node as a standalone. Then, restart the node as a member of the replica set. [source]
The preceding command ensures the correct set of shards is targeted for rolling index builds because no migration for the collection will be allowed to commit. [source]
When the index build completes, shutdown the [`mongod`](https://www.mongodb.com/docs/manual/reference/program/mongod/#mongodb-binary-bin.mongod) instance. Undo the configuration changes made when starting as a standalone to return to its original configuration and restart. [source]
* All fields that make up the unique constraint **must** be mandatory fields. The following model is **not** valid because `id` could be `null`: [source]
The columns passed to `fts_match` must correspond to columns in an existing FTS index. When Turso's query planner detects `fts_match` in a WHERE clause, it routes the query through the FTS index for efficient lookup. [source]
The REINDEX statement deletes and recreates indexes from scratch. It is useful when a collation sequence definition has changed, or to rebuild an index that may have become out of date. [source]
The `fullTextIndex` preview feature provides support for introspection and migration of full text indexes in MySQL and MongoDB. This can be configured using the `@@fulltext` attribute. Existing full text indexes in the database are added to your Prisma schema after introspecting with `db pull`, and new full text indexes added in the Prisma schema are created in the database when using Prisma Migrate. [source]
Label-based filtering is a technique that allows you to filter the results of an ANN search based on a label while using the DiskANN index. Other filters are supported, but will use pgvector's post-filtering (i.e. after the ANN search). [source]
The [citext](https://www.postgresql.org/docs/current/citext.html) extension in PostgreSQL provides a case-insensitive text type. It behaves just like the standard `TEXT` data type but treats values as case-insensitive when comparing or indexing, making it useful for case-insensitive searches and unique constraints. Your Nile database arrives with `citext` extension already enabled, so there's no need to run `create extension`. [source]
* Allows case-insensitive text comparisons without using `LOWER()`. * Simplifies case-insensitive unique constraints and indexes. * Reduces errors when working with user-provided text data like emails or usernames. [source]
Adding an index to an existing table triggers a full table scan, with one read per existing row. [source]
* Which index to use for a query * The order in which to process tables in a join * Whether to use an index or a full table scan [source]
The [`.withSearchIndex`](/api/interfaces/server.QueryInitializer.md#withsearchindex) method defines which search index to query and how Convex will use that search index to select documents. The first argument is the name of the index and the second is a *search filter expression*. A search filter expression is a description of which documents Convex should consider when running the query. [source]
Having a very specific search filter expression will make your query faster and less likely to hit Convex's limits because Convex will use the search index to efficiently cut down on the number of results to consider. [source]
* [Text search](/search/overview.md) returns all documents that include a word for which at least one word in the searched string is a prefix. It does not sort the results by relevance. * [Vector search](/search/vector-search.md) returns results sorted by cosine similarity, but doesn't use an efficient vector index in its implementation. * There is no support for [cron jobs](/scheduling/cron-jobs.md), you should trigger your functions manually from the test. [source]
After you create a wildcard text index, when you insert or update documents, the index updates to include any new string field values. As a result, wildcard text indexes negatively impact performance for inserts and updates. [source]
Text indexes are always [sparse](https://www.mongodb.com/docs/manual/core/index-sparse/#std-label-index-type-sparse). When you create a text index, MongoDB ignores the `sparse` option. [source]
The index only supports queries on fields included in the `wildcardProjection` object. In this example, MongoDB performs a collection scan for the following query because it includes a field that is not present in the `wildcardProjection` object: [source]
Each index suggestion includes an Average Query Targeting score indicating how many documents were read for every document returned for the index's corresponding query shapes. A score of 1 represents very efficient query shapes because every document read matched the query and was returned with the query results. All suggested indexes represent an opportunity to improve query performance. [source]
Indexes should be used for query optimization to improve performance when working with the MongoDB Kotlin Sync Driver. [source]
Indexes can be used to optimize queries when reading data from MongoDB. [source]
in.mongod) did not have to scan all of the documents, and only the three matching documents had to be pulled into memory. This results in a very efficient query. - [`executionStats.totalDocsExamined`](https://www.mongodb.com/docs/manual/reference/explain-results/#mongodb-data-explain.executionStats.totalDocsExamined) display`3` to indicate that MongoDB scanned three documents. [source]
The `DEFAULT` clause specifies a default value to use for the column if no value provided by the user when doing an `INSERT`. If there is no explicit `DEFAULT` clause attached to a column definition, then the default value of the column is `NULL`. [source]
This is the same query but we've swapped the order to descending. In the library, this means that the librarian will start on the right edge of the shelf and scan right-to-left. The librarian still only needs to look at a single book to determine the result so this query is also extremely fast. [source]
The Schema Design Process involves identifying workloads, mapping relationships, and creating indexes to optimize application performance. [source]
| Hash | Covers | Changes when | | --------------- | -------------------------------------------------------------------------------------- | ----------------------------------------- | | `storageHash` | Models, fields, relations, and the full storage layout: tables, columns, keys, indexes | Any schema change | | `executionHash` | Defaults Prisma 8 applies before writes, such as `uuid()` generators | Generated defaults change [source]
Introspection will fetch these limits where they are present in your existing database. This allows Prisma ORM to support indexes and constraints that were previously suppressed and results in better support of MySQL databases utilizing this feature. [source]
The `map` argument allows you to specify a custom name for the index or constraint in the underlying database. This is useful when you want to use a specific naming convention or when the auto-generated name doesn't meet your requirements. [source]
Stored (or persistent) Generated Columns: These columns are computed when a row is inserted or updated and their values are stored in the database. This allows them to be indexed and can improve query performance since the values do not need to be recomputed for each query. [source]
2. Persisted computed columns store the computed value on disk and can be indexed when the expression is deterministic. [source]
When working with relations in Drizzle ORM, especially in applications with significant data or complex queries, optimizing database performance is crucial. Indexes play a vital role in speeding up data retrieval, particularly when querying related data. This section outlines recommended indexing strategies for each type of relationship defined using Drizzle ORM. [source]
<Callout collapsed='Why it is important'> When you query data with related one-to-one information, Drizzle performs a JOIN operation. An index on the foreign key column allows the database to quickly locate the related row in the target table, significantly speeding up the join process. </Callout> [source]
<Callout collapsed='Why it is important'> When you fetch a user with their posts or posts with their authors, joins are performed. Indexing the foreign key (`authorId` in `posts` table) allows the database to efficiently retrieve all posts associated with a given user or quickly find the author of a post. </Callout> [source]
By applying these indexing strategies, you can significantly improve the performance of your Drizzle ORM applications when working with relational data, especially as your data volume grows and your queries become more complex. Remember to choose the indexes that best suit your specific query patterns and application needs. [source]
* **Ingestion phase:** In which they load the source documents, split them into chunks, generate vector embeddings, store them in a database, and optionally generate an index on the stored vectors. * **Conversation phase:** In which they take the user question, generate a vector embedding, search the stored vectors for related chunks, and then send the question together with the related text and perhaps older questions and responses in the conversation and a creative prompt to ChatGPT’s conversation API. When ChatGPT responds, the question and answer are stored and displayed to the user. [source]
The format is `{index1:value1,index2:value2,...}/N`, where N is the number of dimensions and the indices start from 1 (like SQL arrays). Because the format is a bit unusual, it is recommended to use [pgvector's libraries for your favorite language](https://github.com/pgvector/pgvector?tab=readme-ov-file#languages) to insert and query sparse vectors. [source]
The [Bloom Index](https://www.postgresql.org/docs/current/bloom.html) in PostgreSQL is a type of index that can be useful for columns with many distinct values. It is particularly effective when searching across multiple indexed columns using equality queries. Your Nile database arrives with `bloom` extension already enabled, so there's no need to run `create extension`. [source]
* A **single-writer** slot. At most one process across the cluster holds the writer lock at any time. * A **single-checkpointer** slot. Checkpointing is serialized across processes. * A bounded set of **reader slots**. Each active read transaction pins a WAL frame so it is not overwritten by concurrent writers or reclaimed by the checkpointer. * A shared **frame index** so readers in any process can resolve a page number to the latest WAL frame without scanning the WAL from the beginning. [source]
* Triggers that reference the table * Indexes on the table * Foreign key constraints (both as parent and child table) * CHECK constraints * Views that reference the table [source]
Remove a table and all its data, indexes, triggers, and constraints from the database. [source]
`DROP TABLE` permanently removes a table definition and all data stored in the table. All indexes, triggers, and constraints associated with the table are also removed. [source]
* All rows in the table are deleted. * All indexes built on the table are removed. * All triggers associated with the table are removed. * The table entry is removed from the `sqlite_schema` system table. * If foreign key constraints reference the dropped table, those references become invalid. Turso does not prevent dropping a table that is referenced by foreign keys in other tables. * `DROP TABLE` is not allowed while the table is being read or written by another statement in the same connection. [source]
* Unused pages from deleted rows and dropped objects are removed, shrinking the file. * All storage-backed tables are recreated and their rows reinserted, which rebuilds the associated indexes. * `sqlite_sequence` counters used by `AUTOINCREMENT` columns are preserved. * The schema cookie is bumped so that other connections reload their cached schema on their next access. * The page size, reserved space, text encoding, user version, and application ID are preserved exactly. [source]
* A new database file is created at `filename` containing all user tables, indexes, triggers, views, and virtual table content from the source. * Indexes, triggers, and views are recreated after the data is copied so that triggers do not fire during the copy. * Custom index methods (for example FTS and vector) rebuild their backing structures from the copied data. * `sqlite_sequence` counters used by `AUTOINCREMENT` columns are preserved. * Page size, reserved space, text encoding, user version, and application ID are copied from the source. * If the source uses MVCC, the destination is create [source]
Additional fields to index for fast filtering when running search queries. [source]
Additional fields to index for fast filtering when running vector searches. [source]
A single field can have values of any [Convex type](/database/types.md). When there are values of different types in an indexed field, their ascending order is as follows: [source]
Be careful when removing indexes [source]
How do I ensure my Convex [database queries](/database/reading-data/.md) are fast and efficient? When should I define an [index](/database/reading-data/indexes/.md)? What is an index? [source]
These index cards will be sorted by author and live in a separate organizer from the shelves that hold the books. The card catalog should stay small because it only has an index card per book (not the entire text of the book). [source]
This is quite fast because the librarian can quickly find the index cards for Jane Austen. It's still a little bit of work to find the book for each card but the number of index cards is small so this is quite fast. [source]
This query instructs Convex to go to the `by_author` index and find all the entries where `doc.author === "Jane Austen"`. Because the index is sorted by `author`, this is a very efficient operation. This means that Convex can execute this query in the same manner that the librarian can: [source]
This query describes how a librarian might execute the query. The librarian will use the card catalog to find all of the index cards for Isaac Asimov's books. The cards themselves don't have the title of the book so the librarian will need to find every Asimov book on the shelves and look at its title to find the one named *Foundation*. Lastly, this query ends with [`.unique`](/api/interfaces/server.Query.md#unique) because we expect there to be at most one result. [source]
In this index, books are sorted first by the author and then within each author by title. This means that a librarian can use the index to jump to the Isaac Asimov section and quickly find *Foundation* within it. [source]
Because this index sorts by `author` and then by `title`, it also efficiently supports queries like "All books by Isaac Asimov that start with F." We could express this as: [source]
Lastly, imagine that a library patron asks for the book *The Three-Body Problem* but they don't know the author's name. Our `by_author_title` index won't help us here because it's sorted first by `author`, and then by `title`. The title, *The Three-Body Problem*, could appear anywhere in the index! [source]
Instead, you can use [indexes](/database/reading-data/indexes/.md) so that the database only needs to read the relevant documents. [source]
We set these timeouts intentionally for performance and reliability. We do not allow timeouts to be configured. Sometimes fixing a timeout is as simple as adding an index. Other times you'll need to iterate to identify the bottleneck. Some common causes of timeouts: [source]
**SSR can be great for search engines.** Web crawlers are getting better with JavaScript, but they generally do the best job at indexing websites when the content is there on the first load. SSR can do this for you. [source]
Because indexes are fully maintained while hidden, the index is immediately available for use once unhidden. [source]
Always use the default index version when possible. Only override the default version if required for compatibility reasons. [source]
The following example shows how MongoDB uses compound bounds when an index includes a non-array field and multiple array fields. [source]
The following queries *do not* use the index on the `location` field because they query on specific fields within the embedded document: [source]
The index **does not** support queries on `attributes.memory`, because that field was omitted from the index. [source]
- For each element which is an array: - If the element is itself an array (as in an embedded array), the index records the *entire* array as a value. - If the element is an object, the index descends into the object to traverse and index its contents. - If the element is a primitive value, the index records that value. - For non-array, non-object fields, the index records the primitive value into the index. [source]
Because [`min()`](https://www.mongodb.com#mongodb-method-cursor.min) requires an index on a field, and forces the query to use this index, you may prefer the [`$gte`](https://www.mongodb.com/docs/manual/reference/operator/query/gte/#mongodb-query-op.-gte) operator for the query if possible. Consider the following example: [source]
y plan selection. Default is `false` . | | `storageEngine` | document | Optional. Allows users to configure the storage engine on a per-index basis when creating an index. The `storageEngine` option should take the following form: Storage engine configuration options specified when creating indexes are validated and logged to the [oplog](https://www.mongodb.com/docs/manual/reference/glossary/#std-term-oplog) during replication to support replica sets with members that use different storage engines. | [source]
| Parameter | Type | Description | |---|---|---| | `collation` | document | Optional. Specifies the [collation](https://www.mongodb.com/docs/manual/reference/collation/#std-label-collation) for the index. [Collation](https://www.mongodb.com/docs/manual/reference/collation/#std-label-collation) allows users to specify language-specific rules for string comparison, such as rules for lettercase and accent marks. If you have specified a collation at the collection level, then: If you do not specify a collation when creating the index, MongoDB creates the index with the collection's default collati [source]
- If you do not specify a collation when creating the index, MongoDB creates the index with the collection's default collation. - If you do specify a collation when creating the index, MongoDB creates the index with the specified collation. [source]
Because we are working with such a small dataset for the purposes of this tutorial, the Actual Query Execution Time displays `0` seconds, even though we are not using an index. [source]
When all the secondaries have the new index, step down the primary, restart it as a standalone using the procedure described above, and build the index on the former primary: [source]
The command [`serverStatus`](https://www.mongodb.com/docs/manual/reference/command/serverStatus/#mongodb-dbcommand-dbcmd.serverStatus) returns the field [`shardedIndexConsistency`](https://www.mongodb.com/docs/manual/reference/command/serverStatus/#mongodb-serverstatus-serverstatus.shardedIndexConsistency) to report on index inconsistencies when run on the config server primary. [source]
An index supports sort operations on a subset of its keys only when the query includes equality conditions on all prefix keys that precede the sort keys. For more information, see [Sort and Non-prefix Subset of an Index.](https://www.mongodb.com/docs/manual/tutorial/sort-results-with-indexes/#std-label-sort-index-nonprefix-subset) [source]
- `directors` is the first key because it is an equality match. - `year` is indexed in the same order (`1` ) as the query. [source]
The index in its current state indexes all documents. However, this implementation can cause errors when you insert documents missing the `accounts.bank` or `accounts.number` fields. [source]
When using [Stable API](https://www.mongodb.com/docs/manual/reference/stable-api/#std-label-stable-api) V1, all [`createIndexes`](https://www.mongodb.com/docs/manual/reference/command/createIndexes/#mongodb-dbcommand-dbcmd.createIndexes) fields are available with the following exceptions: [source]
The [`explain()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.explain/#mongodb-method-db.collection.explain) method provides information on how MongoDB plans and executes the given query. You may find this information useful when troubleshooting query performance and planning optimizations. [source]

Parameters and configuration

nual/core/indexes/index-types/#std-label-index-types) | | `sparse` | boolean | Optional. If `true` , the index only references documents with the specified field. These indexes use less space but behave differently in some situations (particularly sorts). The default value is`false` . See[Sparse Indexes](https://www.mongodb.com/docs/manual/core/index-sparse/) for more information. The following index types are sparse by default and ignore this option: For a compound index that includes `2dsphere` index keys and keys for other types, only the`2dsphere` index fields determine whether the index r [source]
| Name | Required | Type | Description | | ----------- | -------- | ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ [source]
| Name | Type | Description | | --------------------------- | ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ [source]
| Name | Type | Description | | --------------------------- | ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ [source]
.com/docs/manual/reference/glossary/#std-term-TTL) ) to control how long MongoDB retains documents in this collection. This option only applies to[TTL](https://www.mongodb.com/docs/manual/reference/glossary/#std-term-TTL) indexes. See[Expire Data from Collections by Setting TTL](https://www.mongodb.com/docs/manual/tutorial/expire-data/#std-label-ttl-collections) for more information. If you use TTL indexes created before MongoDB 5.0, or if you want to sync data created in MongDB 5.0 with a pre-5.0 installation, see [Indexes Configured Using NaN](https://www.mongodb.com/docs/manual/tutorial/exp [source]
| Name | Type | Description | | --------------------- | ----------------------------------------- | ------------------------------------------------------------------------------------------------------------ [source]
| Name | Type | Description | | -------------------- | ----------------------------------------- | -------------------------------------------------------------------------------------------------------------- [source]
| Name | Type | Description | | --------------------------- | ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ [source]
| Name | Type | Description | | --------------------------- | ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ [source]
```sql theme={null} — `SET hnsw.iterative_scan = strict_order;` … [source]
```sql theme={null} — `SET ivfflat.iterative_scan = relaxed_order;` … [source]
```sql theme={null} — `SET hnsw.max_scan_tuples = 20000;` … [source]
```sql theme={null} — `SET ivfflat.max_probes = 100;` … [source]
<Info> Note: `USING gin` specifies that this is a GIN index. The extension allows `column1` (text), `column2` (integer), and `column3` (timestamp) to be indexed efficiently using GIN. </Info> [source]
<Info> Note: `USING gist` specifies that this is a GiST index. The extension allows `column1` (text), `column2` (integer), and `column3` (timestamp) to be indexed efficiently using GiST. </Info> [source]
| Field | Type | Description | |---|---|---| | dropIndexes | String | The name of the collection whose indexes to drop. | | index | string or document or array of strings | The index or indexes to drop. To drop all indexes except the `_id` index and the last remaining shard key index from the collection if one exists, specify`"*"` . To drop a single index, specify either the index name, the index specification document (unless the index is a [text](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-text/#std-label-index-type-text) index), or an array of the index name. To drop [source]
* This is the field which will be indexed for full text search. * It must be of type `string`. [source]
| Parameter | Type | Description | |---|---|---| | `indexes` | string or document or array of strings | Optional. Specifies the index or indexes to drop. **To drop all but the _id index from the collection** , omit the parameter. **To drop a single index** , specify either the index name, the index specification document (unless the index is a[text](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-text/#std-label-index-type-text) index), or an array of the index name. To drop a[text](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-text/#std-label-index-type [source]
| Name | Required | Type | Description | | ----------- | -------- | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `map` | **No** | `String` | The name of the underlying primary key constraint in the database.<br /><br /> Not supported for MySQL or MongoDB. | | ` [source]
| Name | Required | Type | Description | | ----------- | -------- | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `fields` | **Yes** | `FieldReference[]` | A list of field names - for example, `["firstname", "lastname"]` [source]
<Info> Note: `USING bloom` specifies that this is a Bloom filter index and `col1 = 4, col2 = 4` defines the number of bits per column to be used in the index (default is 4). </Info> [source]

How-to and procedures

To improve query performance, you can create a [compound text index](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-text/create-text-index/#std-label-compound-text-index-example) and include an equality match in your `$text` queries. If the compound index contains the field used in your equality match, the index scans fewer entries and returns results faster. [source]
You can create multiple indexes on the same key(s) with different collations. To create indexes with the same key pattern but different collations, you must supply unique index names. [source]
You can also enforce a unique constraint on the combination of index key values for a [compound index.](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-compound/#std-label-index-type-compound) [source]
To create a `hidden` index, use the [`db.collection.createIndex()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.createIndex/#mongodb-method-db.collection.createIndex) method with the [hidden](https://www.mongodb.com/docs/manual/reference/method/db.collection.createIndex/#std-label-method-createIndex-hidden) option set to `true`. [source]
Create a compound index on the `ratings.scores.q1` and the `ratings.scores.q2` fields: [source]
use inventory db.products_catalog.createIndexes( [ { "product_attributes.$**" : 1 } ] ) [source]
use inventory db.products_catalog.createIndexes( [ { "$**" : 1 } ] ) [source]
Add an index for each distance function you want to use. [source]
Define a staged index on this table. [source]
To drop a [text](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-text/#std-label-index-type-text) index, specify the index name instead of the index specification document. [source]
Create a wildcard index on all fields excluding `_id` by specifying the `$**` field in the index definition. [source]
CREATE INDEX "idx_content_search" ON "test" USING gin ("content_search"); ``` </CodeTab> </CodeTabs> [source]
CREATE INDEX IF NOT EXISTS "title_search_index" ON "posts" USING gin (to_tsvector('english', "title")); ``` </CodeTab> ```json [ { id: 1, title: 'Planning Your First Trip to Europe' }, { id: 2, title: "Cultural Insights: Exploring Asia's Heritage" }, { id: 3, title: 'Top 5 Destinations for a Family Trip' }, { id: 4, title: 'Essential Hiking Gear for Mountain Enthusiasts' }, { id: 5, title: 'Trip Planning: Choosing Your Next Destination' }, { id: 6, title: 'Discovering Hidden Culinary Gems in Italy' }, { id: 7, title: 'The Ultimate Road Trip Guide for Explorers' }, ]; ``` </CodeTabs> [source]
CREATE INDEX IF NOT EXISTS "search_index" ON "posts" USING gin ((setweight(to_tsvector('english', "title"), 'A') || setweight(to_tsvector('english', "description"), 'B'))); ``` </CodeTab> ```json [ { id: 1, title: 'Planning Your First Trip to Europe', description: 'Get essential tips on budgeting, sightseeing, and cultural etiquette for your inaugural European adventure.', }, { id: 2, title: "Cultural Insights: Exploring Asia's Heritage", description: 'Dive deep into the rich history and traditions of Asia through immersive experiences and local interactions.', }, { id: 3, title: 'Top 5 Destin [source]
CREATE INDEX [name_idx] ON [user] ([name]); CREATE UNIQUE INDEX [email_idx] ON [user] ([email]); ``` </Section> [source]
To create a unique index, use the [`db.collection.createIndex()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.createIndex/#mongodb-method-db.collection.createIndex) method with the `unique` option set to `true`. [source]
To create a wildcard index, use the wildcard specifier (`$**`) as the index key: [source]
To drop an index, you need its name. To get all index names for a collection, run the [`getIndexes()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.getIndexes/#mongodb-method-db.collection.getIndexes) method: [source]
To drop a specific index, use the [`dropIndex()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.dropIndex/#mongodb-method-db.collection.dropIndex) method and specify the index name: [source]
To drop multiple indexes, use the [`dropIndexes()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.dropIndexes/#mongodb-method-db.collection.dropIndexes) method and specify an array of index names: [source]
To learn how to create a collection with a clustered index, see [Date Clustered Index Key Example.](https://www.mongodb.com/docs/manual/core/clustered-collections/#std-label-clustered-collections-index-example) [source]
To override the default version and specify a different version for your 2dsphere index, set the `2dsphereIndexVersion` option when you create an index: [source]
You can create an index on a field containing an array value to improve performance for queries on that field. When you create an index on a field containing an array value, MongoDB stores that index as a multikey index. [source]
To drop an index, insert the index name and run [db.collection.dropIndex().](https://www.mongodb.com/docs/manual/reference/method/db.collection.dropIndex/#std-label-collection-drop-index) [source]
Use indexes like single field and compound indexes to improve query efficiency. [source]
Optimize query performance and index size for wildcard indexes by using the `wildcardProjection` option to include or exclude specific fields. [source]
3. **Performance Optimization**: * Use word\_similarity() for whole word matching * Create indexes on specific columns rather than all text columns * Monitor index size and rebuild when necessary [source]
Define a search index on this table. [source]
To learn about search indexes, see [Search](https://docs.convex.dev/text-search). [source]
Define a staged search index on this table. [source]
Use PyMongo to create indexes including single field, compound, text, geospatial, and MongoDB Search indexes for optimization. [source]
Analyze query performance using explain plan results to determine execution time, index usage, and documents scanned. [source]
To drop a `unique constraint`, the same syntax is used as dropping an index: `ALTER TABLE users DROP INDEX uq_email;`. There's no separate `DROP CONSTRAINT statement` for it in MySQL. [source]
To create a wildcard text index, set the index key to the wildcard specifier (`$**`) and set the index value to `text`: [source]
To override the default version and specify a different version for your text index, set the `textIndexVersion` option when you create an index: [source]
To manually compare the performance of a query using more than one index, you can use the [`hint()`](https://www.mongodb.com/docs/manual/reference/method/cursor.hint/#mongodb-method-cursor.hint) method in conjunction with the [`explain()`](https://www.mongodb.com/docs/manual/reference/method/cursor.explain/#mongodb-method-cursor.explain) method. [source]
To avoid this, use a partial filter expression so the index only includes documents that contain both fields. For more information, see [Partial Index with Unique Constraint](https://www.mongodb.com/docs/manual/core/index-partial/#std-label-partial-index-with-unique-constraints). Recreate the index using the following options: [source]
To learn how to create indexes that the Performance Advisor suggests, see [Create Suggested Indexes.](https://www.mongodb.com#std-label-pa-create-suggested-indexes) [source]
You can create [indexes](https://www.mongodb.com/docs/manual/core/indexes/) suggested by the Performance Advisor directly within the Performance Advisor itself. When you create indexes, keep the ratio of reads to writes on the target collection in mind. Indexes come with a performance cost, but are more than worth the cost for frequent queries on large data sets. To learn more about indexing strategies, see [Indexing Strategies.](https://www.mongodb.com/docs/manual/applications/indexes/) [source]
To better understand what queries can be run over which indexes, see [Introduction to Indexes and Query Performance](/database/reading-data/indexes/indexes-and-query-perf.md). [source]
To optimize queries fetching user data along with their profile information, you should create an index on the `userId` column in the `profile_info` table. [source]
To optimize queries involving users and their posts, create an index on the `authorId` column in the `posts` table. [source]
To optimize queries for users and groups, create indexes on `usersToGroups` table as follows: [source]
You can now query efficiently using operators like `@>`, and PostgreSQL will leverage this index. [source]
Create an index on a table to improve query performance for lookups, joins, and ordering. [source]
You can check the backfill progress via the [*Indexes* pane](/dashboard/deployments/data.md#view-the-indexes-of-a-table) on the dashboard data page. Once it is complete, you can enable the index and use it by removing the `staged` option. [source]
Run `collMod` on the `type` field index and set `prepareUnique` to `true`: [source]
Use the following code to create an index on the `movies` collection of the `sample_mflix` database with the collation locale `"fr"` for string comparisons: [source]
To view the query plan statistics, use the [`explain()`](https://www.mongodb.com/docs/manual/reference/method/cursor.explain/#mongodb-method-cursor.explain) method: [source]
To enable the `fullTextIndex` preview feature, add the `fullTextIndex` feature flag to the `generator` block of the `schema.prisma` file: [source]
CREATE TABLE "composite_example" ( "id" int4, "name" string, CONSTRAINT "composite_example_id_name_unique" UNIQUE("id","name"), CONSTRAINT "custom_name" UNIQUE("id","name") ); ``` </Section> [source]
CREATE TABLE [table] ( [id] int, CONSTRAINT [custom_name_1] UNIQUE([id]) ); [source]
Define an index on this table. [source]
To learn about full text search, see [Indexes](https://docs.convex.dev/text-search). [source]
Use the returnStoredSource option to retrieve only stored fields when storedSource is enabled in the index definition. [source]
Define indexes including single field, compound, unique indexes, and alternate keys to optimize query performance. [source]
Specify an exclusive upper bound for index keys using `cursor.max()` to constrain `find()` query results in MongoDB. [source]
You can use the `map` argument to define **custom constraint and index names** in the underlying database. [source]
To use partial indexes, add the `partialIndexes` feature flag to the `generator` block of your `schema.prisma` file: [source]
You can define a partial index with a raw SQL predicate string using the `raw()` function. This approach supports any valid SQL `WHERE` expression that your database accepts: [source]
You can also define partial indexes using an object literal syntax, which provides type-safety by validating field names and value types against your Prisma schema: [source]
To fix this, add an index to your `Post` model: [source]
To implement full-text search on multiple columns, you can create index on multiple columns and concatenate the columns with `to_tsvector` function: [source]
To implement a unique and case-insensitive `email` handling in PostgreSQL with Drizzle, you can create a unique index on the lowercased `email` column. This way, you can ensure that the `email` is unique regardless of the case. [source]
To implement a unique and case-insensitive `email` handling in SQLite with Drizzle, you can create a unique index on the lowercased `email` column. This way, you can ensure that the `email` is unique regardless of the case. [source]
To implement an upsert query in MySQL with Drizzle you can use `.onDuplicateKeyUpdate()` method. MySQL will automatically determine the conflict target based on the primary key and unique indexes, and will update the row if any unique index conflicts. [source]
You can create indexes on the `jsonb` fields for better query performance, particularly for multi-tenant systems. [source]
Create an index on one or more columns or expressions to accelerate queries [source]
Function form of dot notation — `struct_extract(col, 'field')` is equivalent to `col.field`. Primarily useful in expression indexes, where dot notation cannot be used: [source]
You can create an index across multiple fields at once, query a specific range of data, and change the order of your query result. [Read the complete index documentation](/database/reading-data/indexes/.md) to learn more. [source]
To add an index onto a table, use the [`index`](/api/classes/server.TableDefinition.md#index) method on your table's schema: [source]
To create a staged index, use the following syntax in your `schema.ts`. [source]
You can [create and manage compound indexes in the UI](https://www.mongodb.com/docs/atlas/atlas-ui/indexes/) for deployments hosted in [MongoDB Atlas.](https://www.mongodb.com/docs/atlas) [source]
To create a compound index, see [Create a Compound Index.](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-compound/create-compound-index/#std-label-index-create-compound) [source]
To hide an existing index, you can use the [`collMod`](https://www.mongodb.com/docs/manual/reference/command/collMod/#mongodb-dbcommand-dbcmd.collMod) command or [`mongosh`](https://www.mongodb.com/docs/mongodb-shell/#mongodb-binary-bin.mongosh) helper `db.collection.hideIndex()`. [source]
To unhide a hidden index, you can use the [`collMod`](https://www.mongodb.com/docs/manual/reference/command/collMod/#mongodb-dbcommand-dbcmd.collMod) command or [`mongosh`](https://www.mongodb.com/docs/mongodb-shell/#mongodb-binary-bin.mongosh) helper [`db.collection.unhideIndex()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.unhideIndex/#mongodb-method-db.collection.unhideIndex). You can specify either: [source]
Create a unique compound [multikey](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-multikey/#std-label-index-type-multikey) index on `email` and `name`: [source]
To convert a non-unique index to a [unique index](https://www.mongodb.com/docs/manual/core/index-unique/#std-label-index-type-unique), use the [`collMod`](https://www.mongodb.com/docs/manual/reference/command/collMod/#mongodb-dbcommand-dbcmd.collMod) command. The `collMod` command provides options to verify that your indexed field contains unique values before you complete the conversion. [source]
To create a unique index on the `user_id` field of the `members` collection, run the following command in `mongosh`: [source]
Consider the following wildcard index on the `employees` collection: [source]
To specify the index name, include the `name` option when you create the index: [source]
You can remove a specific index from a collection. You may need to drop an index if you see a negative performance impact, want to replace it with a new index, or no longer need the index. [source]
To drop all indexes except the `_id` index, use the [`dropIndexes()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.dropIndexes/#mongodb-method-db.collection.dropIndexes) method: [source]
To confirm that the index was dropped, run the [`db.collection.getIndexes()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.getIndexes/#mongodb-method-db.collection.getIndexes) method: [source]
You can define the range of coordinates included in a [2d index](https://www.mongodb.com/docs/manual/core/indexes/index-types/geospatial/2d/#std-label-2d-index). By default, 2d indexes have longitude and latitude boundaries of: [source]
To change the location range of a 2d index, specify the `min` and `max` options when you create the index: [source]
Create a 2d index on the `address` field. Specify the following location bounds: [source]
You can use the 2d index to perform calculations on location data, such as [proximity queries.](https://www.mongodb.com/docs/manual/core/indexes/index-types/geospatial/2d/query/proximity-flat-surface/#std-label-2d-index-proximity-query) [source]
To index all of the coordinate pairs in the `locs` array, create a 2d index on the `locs` field: [source]
To index all of the `loc` values in the `addresses` array, create a 2d index on the `addresses.loc` field: [source]
To create an index, use the [`db.collection.createIndex()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.createIndex/#mongodb-method-db.collection.createIndex) method. Your operation should resemble this prototype: [source]
Create a [compound multikey index](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-compound/#std-label-index-type-compound) on the `item` and `ratings` fields: [source]
You can create indexes on embedded documents as a whole. However, only queries that specify the **entire** embedded document use the index. Queries on a specific field within the document do not use the index. [source]
Create an index on the `location` field: [source]
You can create an index on a single field to improve performance for queries on that field. [source]
To create a single-field index, use the [`db.collection.createIndex()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.createIndex/#mongodb-method-db.collection.createIndex) method: [source]
Consider a school administrator who frequently looks up students by their GPA. You can create an index on the `gpa` field to improve performance for those queries: [source]
You can create indexes on fields within embedded documents. Indexes on embedded fields can fulfill queries that use [dot notation.](https://www.mongodb.com/docs/manual/reference/glossary/#std-term-dot-notation) [source]
Create a compound index on the `inventory` collection that contains the following fields: [source]
You can create a wildcard index that supports queries on all possible document fields. Wildcard indexes support queries on arbitrary or unknown field names. [source]
To include or exclude fields in a wildcard index, specify the chosen fields in the `wildcardProjection` option: [source]
To learn how to use wildcard projection with a compound wildcard index to filter fields, see [Filter Fields with a `wildcardProjection`.](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-wildcard/index-wildcard-compound/#std-label-wc-compound-index-wcProject) [source]
Use a compound wildcard index instead. The compound wildcard index is easier to write, easier to maintain, and is unlikely to reach the 64 index collection limit. [source]
To create a [partial](https://www.mongodb.com/docs/manual/core/index-partial/#std-label-index-type-partial) compound wildcard index, you can use the `partialFilterExpression` option to specify a filter expression so that the index only includes documents that match the filter condition. `partialFilterExpression` can cover fields included or not included in the index. [source]
Create a wildcard index that includes the `ship` field: [source]
Consider the following wildcard index on a `books` collection: [source]
To view the created indexes, run the [`getIndexes()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.getIndexes/#mongodb-method-db.collection.getIndexes) method: [source]
To change the other index options, drop the existing index with [`db.collection.dropIndex()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.dropIndex/#mongodb-method-db.collection.dropIndex) before running [`db.collection.createIndex()`](https://www.mongodb.com#mongodb-method-db.collection.createIndex) with the new options. [source]
To see the indexes in the `pets` collection, run the [`getIndexes()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.getIndexes/#mongodb-method-db.collection.getIndexes) method: [source]
To drop the index `catIdx`, you can use either the index name: [source]
To confirm that the index was dropped, run the `getIndexes()` method again: [source]
To support the query on the `quantity` field, add an index on the `quantity` field: [source]
To support the query, add a [compound index](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-compound/#std-label-index-type-compound). With compound indexes, the order of the fields matter. [source]
Avoid performing rolling index and replicated index build processes concurrently as it might lead to unexpected issues, such as broken builds and crash loops. [source]
To create [unique indexes](https://www.mongodb.com/docs/manual/core/index-unique/#std-label-index-type-unique) using the following procedure, you must stop all writes to the collection during this procedure. [source]
Make sure you are not performing [DDL operations](https://www.mongodb.com/docs/manual/reference/ddl-operations/#std-label-ddl-operations) while conducting the rolling index build. [source]
To improve query performance, you can create a [compound index](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-compound/#std-label-index-type-compound) that narrows the documents that queries read. For example, if you want to improve performance for queries on `status` and `product_type`, you could create a compound index on those two fields. [source]
Ensure that equality fields always come first. Placing equality fields first keeps the remaining index fields in sorted order. Choose whether to use a sort or range field next based on your index's specific needs: [source]
To improve query performance, create an index on the `directors` and `year` fields: [source]
To ensure your database adheres to your application design, you can strategically create indexes to combine index properties with schema validation. [source]
To design your database so that it confines its documents to the application’s rules, combine a unique index and schema validation on your database using the following procedure. [source]
To enforce the application’s rules, create an index on the `accounts.bank` and `accounts.number` fields with the following characteristics: [source]
Override MongoDB's default index selection for queries using the `cursor.hint()` method to specify a particular index. [source]
You can also use index attributes to speed up querying. An additional benefit is that indexed attributes can be used with comparison operators for where queries like `$gt`, `$lt`, `$gte`, and `$lte` and can be used in `order` clauses. [source]
Consider deleting unused indexes to improve application performance. For more information, see [Remove Unnecessary Indexes.](https://www.mongodb.com/docs/manual/data-modeling/design-antipatterns/unnecessary-indexes/#std-label-unnecessary-indexes-antipattern) [source]
To confirm whether a query used an index, run the query with the [`explain()`](https://www.mongodb.com/docs/manual/reference/method/cursor.explain/#mongodb-method-cursor.explain) option. [source]
To force MongoDB to use a particular index, use [cursor.hint() (mongosh method)](https://www.mongodb.com/docs/manual/reference/method/cursor.hint/#std-label-cursor-hint) when testing indexes. [source]
Use **cursor-based pagination** for large datasets or infinite scroll. Cursor-based pagination scales better because it uses indexed columns to find the starting position instead of traversing skipped rows: [source]
Partition the MongoDB Search index to support more index objects. [source]
Create a wildcard text index using the `$**` specifier to enable $text queries on all string fields in a collection. [source]
Use a compound text index with an equality match to limit the number of entries scanned during $text queries for better performance. [source]
To perform similarity search, you need to create a table with a vector column and an `HNSW` or `IVFFlat` index on this column for better performance: [source]
Ensure that your queries are designed to take advantage of indexes for row filtering. The absence of suitable indexes forces SQLite to resort to full table scans, incrementally increasing the read count by one for each row in the table. Efficient indexing is key to minimizing this overhead. [source]
Incorporating necessary indexes at the table creation stage is a best practice. Adding indexes to tables that already contain rows triggers a full table scan, with each existing row necessitating one read. Proactive index management is crucial for maintaining optimal database performance. [source]
Define a vector index on this table. [source]
To learn about vector indexes, see [Vector Search](https://docs.convex.dev/vector-search). [source]
Define a staged vector index on this table. [source]
To add a search index onto a table, use the [`searchIndex`](/api/classes/server.TableDefinition.md#searchindex) method on your table's schema. For example, if you want an index which can search for messages matching a keyword in a channel, your schema could look like: [source]
To add a vector index onto a table, use the [`vectorIndex`](/api/classes/server.TableDefinition.md#vectorindex) method on your table's schema. Every vector index has a unique name and a definition with: [source]
Create a text index on the `content`, `users.comments`, and `users.profiles` fields. Set the index `name` to `InteractionsTextIndex`: [source]
You can create a text index that contains every document field with string data in a collection. These text indexes are called **wildcard text indexes**. Wildcard text indexes support `$text`[queries](https://www.mongodb.com/docs/manual/core/text-search/on-prem/#std-label-text-search-on-prem) on unknown, arbitrary, or dynamically generated fields. [source]
Create a wildcard text index on the `blog` collection: [source]
To specify a language for the text index, see [Specify Language for Text Indexes on Self-Managed MongoDB.](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-text/specify-text-index-language/#std-label-specify-text-index-language) [source]
You can also create a named compound ID or compound unique constraint by using the `@@id` or `@@unique` attributes' `name` field. For example: [source]
To view collections with slow queries and see suggested indexes, you must have [`Project Read Only`](https://www.mongodb.com/docs/atlas/reference/user-roles/#mongodb-authrole-Project-Read-Only) access or higher to the project. [source]
You can also adjust the time range the Performance Advisor takes into account when suggesting indexes by using the Time Range dropdown at the top of the Performance Advisor. [source]
To view the query plan selected, chain the [`cursor.explain("executionStats")`](https://www.mongodb.com/docs/manual/reference/method/cursor.explain/#mongodb-method-cursor.explain) cursor method to the end of the **find** command: [source]
Check the [`explain.executionStats.executionTimeMillis`](https://www.mongodb.com/docs/manual/reference/explain-results/#mongodb-data-explain.executionStats.executionTimeMillis) field to see the execution time in milliseconds. This shows the total time, including the time it takes to build and select a query plan in addition to the time it takes the plan to execute. [source]
Check the [`inputStage.stage`](https://www.mongodb.com/docs/manual/reference/explain-results/#mongodb-data-explain.executionStats.executionStages.inputStage) field for each execution stage: [source]
Check the total values for the query and ensure that [`executionStats.totalDocsExamined`](https://www.mongodb.com/docs/manual/reference/explain-results/#mongodb-data-explain.executionStats.totalDocsExamined) does not show a value greater than `executionStats.totalKeysExamined`. [source]
Use `$natural` in conjunction with `cursor.hint()` to perform a collection scan to return documents in [natural order.](https://www.mongodb.com/docs/manual/reference/glossary/#std-term-natural-order) [source]
CREATE TABLE "user_nulls_example" ( "id" integer UNIQUE NULLS NOT DISTINCT, "id2" integer CONSTRAINT "custom_name" UNIQUE NULLS NOT DISTINCT ); ``` </Section> [source]
You can assign relative weights to indexed columns to influence the BM25 relevance score. [source]
You can imagine that Convex is a physical library storing documents as physical books. In this world, every time you add a document to Convex with [`db.insert("books", {...})`](/api/interfaces/server.GenericDatabaseWriter.md#insert) a librarian places the book on a shelf. [source]
Use collation to specify language-specific rules for string comparison, such as rules for lettercase and accent marks. The [collation document](https://www.mongodb.com/docs/manual/reference/collation/#collation-document) contains a `locale` field which indicates the [ICU Locale code](https://unicode-org.github.io/icu/userguide/locale/), and may contain other fields to define collation behavior. [source]
Use the vectorSearch type to index vector embeddings for vector search operations in MongoDB. [source]
Specify the inclusive lower bound for an index using `cursor.min()` to constrain `find()` results in MongoDB. [source]
* You never hand-write migration steps: declare indexes and validators in the contract (step 2) and `migration plan` derives the changes. * If a `migrate` run is interrupted, rerun it to resume. After fixing anything by hand, run `db sign` so the signature matches the database again. * Prisma 8 adds strict `$jsonSchema` validators by default. Make sure existing documents pass them before running in production: once the validators are live, writes to documents that don't match the contract fail with `Document failed validation`. [source]
Use one polymorphic collection when the variants are handled together far more than separately: a notifications collection of email, SMS, and push messages read as one stream. Prefer separate collections when the types rarely appear in the same query or need very different indexes. [source]
If you use the [Prisma VS Code extension](https://marketplace.visualstudio.com/items?itemName=Prisma.prisma) (or our [language server in another editor](https://www.prisma.io/docs/orm/v7/more/dev-environment/editor-setup)), the warning is augmented with a Quick Fix that adds the required index for you: [source]
You can now specify indexes for `pg_vector` and utilize `pg_vector` functions for querying, ordering, etc. [source]
You can access individual elements of an array using the `[index]` syntax. The first element has an index of one: [source]
Use `ORDER BY score ASC` or `ORDER BY score DESC` depending on your preference for result ordering. When used in SELECT, the FTS index automatically provides scored results. [source]
Run a vector search on the given table and index. [source]
You can define a `"users"` table, optionally with an [index](/database/reading-data/indexes/.md) for efficient looking up the users in the database. [source]
You can query for documents inserted in the current transaction using a commit timestamp index. This can be useful inside components or nested function where you may not have context from the parent transaction. [source]
You can feel free to query an index in the same deploy that defines it. Convex will ensure that the index is backfilled before the new query and mutation functions are registered. [source]
You can then efficiently find the top 10 highest scoring players using your index and [`take(10)`](/api/interfaces/server.Query.md#take): [source]
You can also order by any attribute that is indexed and has a checked type. [source]
Add indexes and checked types to your attributes from the [Explorer on the Instant dashboard](/dash?t=explorer) or from the [cli](/docs/cli). [source]
Add indexes and checked types to your attributes from the [Explorer on the Instant dashboard](/dash?t=explorer) or from the [cli with Schema-as-code](/docs/modeling-data). [source]
To learn more about rebuilding indexes, see [Build Indexes on Replica Sets.](https://www.mongodb.com/docs/manual/tutorial/build-indexes-on-replica-sets/) [source]
You can drop any index except the default index on the `_id` field. To drop the `_id` index, you must drop the entire collection. [source]
To use an index for string comparisons, an operation must also specify the same collation. If an operation specifies a different collation than the index specifies, the index cannot support string comparisons on the indexed fields. [source]
You can specify collation for a collection or a view, an index, or specific operations that support collation. [source]
To create a `text` or `2d` index on a collection that has a non-simple collation, you must explicitly specify `{collation: {locale: "simple"} }` when creating the index. [source]
To hide or unhide existing indexes, you can use the following [`mongosh`](https://www.mongodb.com/docs/mongodb-shell/#mongodb-binary-bin.mongosh) methods: [source]
You can create collections and indexes inside a [distributed transaction](https://www.mongodb.com/docs/manual/core/transactions/#std-label-transactions-create-collections-indexes) if the transaction is **not** a cross-shard write transaction. [source]
Ensure that your [oplog](https://www.mongodb.com/docs/manual/reference/glossary/#std-term-oplog) is large enough to permit the indexing or re-indexing operation to complete without falling too far behind to catch up. See the [oplog sizing](https://www.mongodb.com/docs/manual/core/replica-set-oplog/#std-label-replica-set-oplog-sizing) documentation for additional information. [source]
Run the following commands on your primary node to hide the secondary that will build the new index. [source]
Run the following command on your primary to unhide the secondary node that built the index. In this example, the secondary node that built the index is the third node in `cfg.members`. [source]
To check if a sharded collection has inconsistent indexes, see [Find Inconsistent Indexes Across Shards.](https://www.mongodb.com/docs/manual/tutorial/manage-indexes/#std-label-manage-indexes-find-inconsistent-indexes) [source]
Consider the same index on a collection where `status` has *nine* values distributed across the collection: [source]
You can customize the constraint name with the `name` field: `@@unique(name: "authorTitle", [authorId, title])` [source]
To use the `hidden` option with [`db.collection.createIndex()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.createIndex/#mongodb-method-db.collection.createIndex), you must have [featureCompatibilityVersion](https://www.mongodb.com/docs/manual/reference/command/setFeatureCompatibilityVersion/#std-label-view-fcv) set to `6.0` or greater. [source]
To verify, run [`db.collection.getIndexes()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.getIndexes/#mongodb-method-db.collection.getIndexes) on the `addresses` collection: [source]
To verify, run [`db.collection.getIndexes()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.getIndexes/#mongodb-method-db.collection.getIndexes) on the `restaurants` collection: [source]
Consider the following [`db.collection.createIndex()`](https://www.mongodb.com#mongodb-method-db.collection.createIndex) operation: [source]
To use [`db.collection.createIndex()`](https://www.mongodb.com#mongodb-method-db.collection.createIndex) in a transaction, the transaction must use read concern [`"local"`](https://www.mongodb.com/docs/manual/reference/read-concern-local/#mongodb-readconcern-readconcern.-local-). If you specify a read concern level other than [`"local"`](https://www.mongodb.com/docs/manual/reference/read-concern-local/#mongodb-readconcern-readconcern.-local-), the transaction fails. [source]
To set the [commit quorum](https://www.mongodb.com/docs/manual/reference/command/createIndexes/#std-label-createIndexes-cmd-commitQuorum), use [`createIndex()`](https://www.mongodb.com#mongodb-method-db.collection.createIndex) to specify the `commitQuorum` value. [source]
use inventory db.products_catalog.createIndexes( [ { "$**" : 1 } ], { "wildcardProjection" : { "product_attributes.colors" : 1, "product_attributes.material" : 1 } } ) [source]
use inventory db.products_catalog.createIndexes( [ { "$**" : 1 } ], { "wildcardProjection" : { "product_attributes.colors" : 0, "product_attributes.material" : 0 } } ) [source]
To run [`db.collection.getIndexes()`](https://www.mongodb.com#mongodb-method-db.collection.getIndexes) when access control is enforced, users must have privileges to [`listIndexes`](https://www.mongodb.com/docs/manual/reference/privilege-actions/#mongodb-authaction-listIndexes) on the collection. [source]
Run the explain method on a MongoDB Vector Search query to view the $vectorSearch query plan, execution statistics, and vector tracing details. [source]
Enable or disable writing temporary files to disk for sort operations exceeding 100MB memory limit using `cursor.allowDiskUse()`. [source]
Discover how to use `cursor.explain()` to obtain query plan details and execution statistics for MongoDB queries. [source]
To see how many documents were scanned to return the query, view the query's `executionStats`: [source]
To avoid an in-memory sort, place the range filter after the sort predicate. For more information on in-memory sorts, see `cursor.allowDiskUse()`. [source]
Run the query you want to evaluate with the [`explain()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.explain/#mongodb-method-db.collection.explain) method: [source]

Examples and snippets

```sql theme={null} — `CREATE TABLE orders (` … [source]
```sql theme={null} — `-- Create GiST index` … [source]
```sql — `CREATE UNIQUE INDEX "User_email_key" ON "User" ("email") WHERE (status = 'active');` … [source]
```sql — `CREATE UNIQUE INDEX "User_email_key" ON "User" ("email") WHERE status = 'active';` … [source]
```sql theme={null} — `CREATE INDEX gin_idx ON my_table` … [source]
```sql theme={null} — `CREATE INDEX gist_idx ON my_table` … [source]
```sql theme={null} — `CREATE TABLE employees (` … [source]
```sql theme={null} — `CREATE INDEX idx_emp_location ON employees USING spgist(emp_location);` … [source]
```sql theme={null} — `CREATE INDEX idx_employees_hire_date_brin` … [source]
```prisma title="schema.prisma" showLineNumbers — `model User {` … [source]
```prisma title="schema.prisma" showLineNumbers — `model Post {` … [source]
```prisma title="schema.prisma" showLineNumbers — `model User {` … [source]
```prisma title="schema.prisma" showLineNumbers — `model User {` … [source]
```sql theme={null} — `-- Index only active orders` … [source]
```sql theme={null} — `-- Index on lowercase email for case-insensitive lookups` … [source]
```sql theme={null} — `CREATE INDEX idx_name ON users(name);` … [source]
```sql theme={null} — `CREATE UNIQUE INDEX idx_users_email_unique ON users (email);` … [source]
``` — `// ❌` … [source]
```sql theme={null} — `CREATE TABLE products (` … [source]
```sql theme={null} — `-- Create GiST index` … [source]
``` — `const messages = await ctx.db` … [source]
``` — `// DOES NOT COMPILE!` … [source]
```prisma — `model Post {` … [source]
```prisma highlight=2,8,11,13;normal — `model User {` … [source]
```prisma highlight=2,13;normal — `model User {` … [source]
```prisma title="schema.prisma" showLineNumbers — `model Example {` … [source]
For example, if there is an index of messages on `["projectId", "priority"]`, a range searching for "messages in 'myProjectId' with priority at least 100" would look like: [source]
``` — `export default defineSchema({` … [source]
```sql — `CREATE TABLE "Example" (` … [source]
```sql theme={null} — `DROP INDEX gin_idx;` … [source]
```sql theme={null} — `CREATE INDEX articles_content_idx ON articles USING gin (content gin_bigm_ops);` … [source]
```sql theme={null} — `CREATE TABLE employees (` … [source]
```sql theme={null} — `CREATE TABLE network_devices (` … [source]
```sql theme={null} — `CREATE [UNIQUE] INDEX [IF NOT EXISTS] [schema-name.]index-name` … [source]
```sql theme={null} — `-- Index on an arithmetic expression` … [source]
```sql theme={null} — `CREATE TABLE employees (` … [source]
```sql theme={null} — `CREATE TABLE tasks (` … [source]
db.collection.createIndex( <key and index type specification>, { unique: true } ) [source]
db.users.createIndex( { "email": 1 }, { unique: true } ) [source]
db.users.createIndex( { password : 1 }, { name: "unique_index", unique: true } ) [source]
db.users.createIndex( { password : 1 }, { name: "unique_sparse_index", unique: true, sparse: true } ) [source]
db.users.createIndex( { password : 1 }, { name: "sparse_index", sparse: true } ) [source]
db.users.createIndex( { password : 1 }, { name: "basic_index" } ) [source]
db.<collection>.dropIndex("<indexName>") [source]
db.students.createIndex( { grades: 1 } ) [source]
db.survey3.createIndex( { "ratings.scores.q1": 1, "ratings.scores.q2": 1 } ) [source]
db.products.createIndex( { "$**" : 1 }, { "wildcardProjection" : { "attributes.memory" : 0 } } ) [source]
db.movies.createIndex( { "awards.$**": 1 } ) [source]
db.movies.createIndex( { "$**": 1 } ) [source]
db.movies.createIndex( { "$**": 1 }, { "wildcardProjection": { "tomatoes.viewer": 1, "tomatoes.critic": 1 } } ) [source]
db.movies.createIndex( { "$**": 1 }, { "wildcardProjection": { "tomatoes.viewer": 0, "tomatoes.critic": 0 } } ) [source]
```prisma title="schema.prisma" showLineNumbers — `model CompoundUnique {` … [source]
``` — `defineTable({` … [source]
``` — `const foundation = await ctx.db` … [source]
```prisma title="schema.prisma" showLineNumbers — `model Example {` … [source]
```prisma title="schema.prisma" showLineNumbers — `model Example {` … [source]
```prisma title="schema.prisma" showLineNumbers — `model Example {` … [source]
```sql theme={null} — `CREATE INDEX ON wiki_documents USING hnsw (embedding vector_l2_ops);` … [source]
```sql theme={null} — `CREATE INDEX ON wiki_documents USING hnsw (embedding vector_ip_ops);` … [source]
```sql theme={null} — `CREATE INDEX ON wiki_documents USING hnsw (embedding vector_cosine_ops);` … [source]
```sql theme={null} — `CREATE INDEX ON wiki_documents USING hnsw (embedding vector_cosine_ops) WITH (m = 16, ef_construction = 100);` … [source]
```sql theme={null} — `CREATE INDEX ON wiki_documents USING ivfflat (embedding vector_l2_ops) WITH (lists = 100);` … [source]
```sql theme={null} — `CREATE INDEX ON wiki_documents USING ivfflat (embedding vector_ip_ops) WITH (lists = 100);` … [source]
```sql theme={null} — `CREATE INDEX ON wiki_documents USING ivfflat (embedding vector_cosine_ops) WITH (lists = 100);` … [source]
```sql theme={null} — `CREATE INDEX movies_idx ON movies (libsql_vector_idx(embedding));` … [source]
```sql theme={null} — `CREATE INDEX movies_idx ON movies (libsql_vector_idx(embedding))` … [source]
```sql — `-- CreateTable` … [source]
```sql title="migration" — `-- DropForeignKey` … [source]
```sql title="migration" — `-- DropForeignKey` … [source]
```sql — `CREATE TABLE "Example" (` … [source]
```sql — `CREATE TABLE "Example" (` … [source]
```sql — `CREATE TABLE "Example" (` … [source]
```sql — `-- As of now drizzle-kit only supports index name and on() param, so you have to add order manually` … [source]
```ts — `// CREATE INDEX custom_idx ON table USING GIST (geom);` … [source]
```sql theme={null} — `-- Create a table for our road network` … [source]
```sql theme={null} — `-- Create a table for storing points of interest` … [source]
```sql theme={null} — `-- Create a table for phone number prefixes` … [source]
```sql theme={null} — `-- Create a table for routing rules` … [source]
```sql theme={null} — `-- Create a table with a seg column` … [source]
```sql theme={null} — `CREATE INDEX index-name ON table-name USING method-name (columns...);` … [source]
```prisma — `enum UserRole {` … [source]
```prisma title="schema.prisma" showLineNumbers — `model Post {` … [source]
``` — `movieEmbeddings: defineTable({` … [source]
``` — `Add column to `users` table` … [source]
In MySQL, a `unique constraint` and a `unique index` are essentially the same thing. — `Under the hood, MySQL implements a unique constraint as a unique index.` … [source]
```ts — `// CREATE INDEX ON items USING hnsw (embedding vector_l2_ops);` … [source]
```ts — `// CREATE INDEX ON items USING hnsw (embedding halfvec_l2_ops);` … [source]
```ts — `// CREATE INDEX ON items USING hnsw (embedding sparsevec_l2_ops);` … [source]
```ts — `// CREATE INDEX "hamming_index" ON "items" USING hnsw ("embedding" bit_hamming_ops);` … [source]
```sql theme={null} — `-- 1. Shared data table` … [source]
```sql theme={null} — `-- 1. Tenant-aware table` … [source]
```sql theme={null} — `-- 1. Create a label column` … [source]
```sql theme={null} — `CREATE INDEX ON wiki_documents USING hnsw ((embedding::halfvec(3)) halfvec_l2_ops);` … [source]
```sql theme={null} — `Column | Type | Collation | Nullable | Default` … [source]
```sql theme={null} — `Column | Type | Collation | Nullable | Default` … [source]
```sql theme={null} — `Column | Type | Collation | Nullable | Default` … [source]
``` — `const messages = await ctx.db` … [source]
``` — `const topScoringPlayers = await ctx.db` … [source]
``` — `// query the top 10 highest scoring players in Canada.` … [source]
``` — `const austenBooks = await ctx.db` … [source]
``` — `const asimovBooksStartingWithF = await ctx.db` … [source]
```ts — `const user = await prisma.user.findUnique({` … [source]
```ts highlight=3;edit — `const user = await prisma.user.findUnique({` … [source]
```prisma title="schema.prisma" showLineNumbers — `generator client {` … [source]
```sql — `CREATE UNIQUE NONCLUSTERED INDEX [User_email_key] ON [dbo].[User]([email]) WHERE ([status]='active');` … [source]
```prisma title="schema.prisma" showLineNumbers — `model User {` … [source]
```sql theme={null} — `PRAGMA index_info(index-name);` … [source]
```sql theme={null} — `PRAGMA index_xinfo(index-name);` … [source]
db.runCommand( { collMod: "apples", index: { keyPattern: { type: 1 }, prepareUnique: true } } ) [source]
db.<collection>.dropIndexes( [ "<index1>", "<index2>", "<index3>" ] ) [source]
db.<collection>.dropIndexes() [source]
db.students.createIndex( { "location.state": 1 } ) [source]
db.movies.createIndex( { title: 1, runtime: "hashed" } ) [source]
db.movies.createIndex( { "title": 1 }, { }, "majority" ) [source]
db.products.createIndexes( [ { "manufacturer": 1}, { "category": 1 } ], { collation: { locale: "fr", strength: 2 } }) [source]
db.getSiblingDB("examples").invoices.createIndexes( { "invoices" : 1 }, { }, "majority" ) [source]
db.cakeSales.createIndexes( [ { "type": 1 }, { "orderDate": 1 }, { "state": 1 }, { "orderDate": 1, "state": -1 } ] ) [source]
db.inventory.createIndex( { quantity: 1 } ) [source]
db.records.createIndex( { username: 1 } ) [source]
```ts copy — `export const users = mysqlTable('users', {` … [source]
```ts — `await db.select()` … [source]
```ts copy — `export const users = mysqlTable('users', {` … [source]
```ts — `await db.select()` … [source]
```ts copy — `export const users = mysqlTable('users', {` … [source]
```ts — `await db.select()` … [source]
```sql theme={null} — `-- Optimize a specific FTS index` … [source]
```sql theme={null} — `-- All of these automatically update the FTS index` … [source]
```prisma title="schema.prisma" — `model Post {` … [source]
```prisma — `model User {` … [source]
```prisma title="prisma/schema.prisma" — `model Comment {` … [source]
```prisma no-lines — `@@index(fields: [title, author])` … [source]
```prisma no-lines — `@@index(fields: [title(length:10), author])` … [source]
```prisma no-lines — `@@index(_ fields: FieldReference[], map: String?, where: raw(String) | { field: value }?)` … [source]
```prisma — `model Post {` … [source]
```prisma — `model Post {` … [source]
```prisma — `type Address {` … [source]
```prisma — `model Post {` … [source]
```prisma title="schema.prisma" showLineNumbers — `model Post {` … [source]
```prisma title="schema.prisma" showLineNumbers — `model Example {` … [source]
```prisma title="schema.prisma" highlight=6;add showLineNumbers — `model Post {` … [source]
``` — `export const schema = defineSchema({` … [source]
``` — `// Fetch a single document by ID:` … [source]
``` — `// convex/schema.ts` … [source]
``` — `users: defineTable({` … [source]
``` — `users: defineTable({` … [source]
``` — `import { defineSchema, defineTable } from "convex/server";` … [source]
``` — `import { defineSchema, defineTable } from "convex/server";` … [source]
``` — `// Get the top 20 most liked messages of all time, using the "by_likes" index.` … [source]
``` — `import { query } from "./_generated/server";` … [source]
``` — `import { defineSchema, defineTable } from "convex/server";` … [source]
``` — `export default defineSchema({` … [source]
``` — `import { defineSchema, defineTable } from "convex/server";` … [source]
``` — `import { defineSchema, defineTable } from "convex/server";` … [source]
``` — `import { defineSchema, defineTable } from "convex/server";` … [source]
``` — `// ❌` … [source]
```prisma title="schema.prisma" showLineNumbers — `generator client {` … [source]
```prisma title="schema.prisma" showLineNumbers — `generator js {` … [source]
```sql theme={null} — `SET hnsw_ef = 100;` … [source]
```sql theme={null} — `SET ivfflat_probes = 100;` … [source]
``` — `import { defineSchema, defineTable } from "convex/server";` … [source]
``` — `foods: defineTable({` … [source]
Docs in MCP: "How do I create a compound index in MongoDB?" — `"How do I create a compound index in MongoDB?"` [source]
```text — `"How do I create a compound index in MongoDB?"` … [source]
Here is an example of pgfence analyzing a migration that adds an index without `CONCURRENTLY`: [source]
```sql — `-- prisma/migrations/20240115_add_index/migration.sql` … [source]
```sql — `-- AlterTable` … [source]
```sql — `CREATE TABLE users (` … [source]
```sql — `-- PostgreSQL approach` … [source]
```sql — `CREATE TABLE "Example" (` … [source]
```sql — `CREATE INDEX "my_custom_index_name" ON "Post" ("title");` … [source]
```sql — `-- drizzle/20242409125510_premium_mister_fear/migration.sql` … [source]
```typescript — `// Note that MySQL automatically determines targets based on the primary key and unique indexes` … [source]
```sql — `CREATE TABLE `users` (` … [source]
```sql — `CREATE INDEX `profile_info_user_id_idx` ON `profile_info` (`user_id`);` … [source]
```sql — `CREATE INDEX `posts_author_id_idx` ON `posts` (`author_id`);` … [source]
```sql — `CREATE INDEX `users_to_groups_user_id_idx` ON `users_to_groups` (`user_id`);` … [source]
```typescript — `// Note that SingleStore automatically determines targets based on the primary key and unique indexes` … [source]
```sql — `CREATE TABLE `posts` (` … [source]
```sql — `CREATE TABLE `users_table` (` … [source]
```sql theme={null} — `Column | Type | Collation | Nullable | Default` … [source]
```sql theme={null} — `Column | Type | Collation | Nullable | Default` … [source]
```sql theme={null} — `Column | Type | Collation | Nullable | Default` … [source]
```sql theme={null} — `Column | Type | Collation | Nullable | Default` … [source]
```sql theme={null} — `Column | Type | Collation | Nullable | Default` … [source]
```sql theme={null} — `Column | Type | Collation | Nullable | Default` … [source]
```sql theme={null} — `CREATE INDEX bloom_idx ON my_table` … [source]
```sql theme={null} — `CREATE INDEX citext_idx ON my_table (column1);` … [source]
```sql theme={null} — `-- Create a table for response times` … [source]
```sql theme={null} — `CREATE INDEX movies_idx` … [source]
```sql theme={null} — `-- Create the FTS table` … [source]
```sql theme={null} — `-- Create an FTS index` … [source]
```sql theme={null} — `-- All columns use the default tokenizer` … [source]
```sql theme={null} — `CREATE INDEX idx_articles ON articles USING fts (title, body)` … [source]
```sql theme={null} — `-- Create a table` … [source]
```sql theme={null} — `CREATE TABLE products (` … [source]
```sql theme={null} — `CREATE TABLE orders (` … [source]
```sql theme={null} — `-- Single-column index` … [source]
```sql theme={null} — `CREATE TABLE products (` … [source]
```sql theme={null} — `CREATE INDEX idx_x ON locations(struct_extract(pos, 'x'));` … [source]
```sql theme={null} — `CREATE INDEX idx_tg ON contacts(union_extract(platform, 'telegram'));` … [source]
```sql theme={null} — `DROP INDEX idx_users_email;` … [source]
```sql theme={null} — `-- Given: CREATE UNIQUE INDEX idx ON t(a, b) WHERE c > 0` … [source]
db.runCommand( { createIndexes: "salesData", indexes: [ { key: { tenantId: 1, "customFields.$**": 1 }, name: "tenant_customFields" } ] } ) [source]
db.runCommand( { createIndexes: "salesData", indexes: [ { key: { tenantId: 1, "$**": 1 }, name: "tenant_customFields_projection", wildcardProjection: { "customFields.addr": 1, "customFields.name": 1 } } ] } ) [source]
db.runCommand( { createIndexes: "salesData", indexes: [ { key: { tenantId: 1, "customFields.$**": 1 }, name: "tenant_customFields_partial", partialFilterExpression: { tenantRegion: 1 } } ] } ) [source]
db.runCommand( { dropIndexes: <string>, index: <string|document|arrayofstrings>, writeConcern: <document>, comment: <any> } ) [source]
```sql theme={null} — `-- Rebuild every index in the database` … [source]
```typescript filename="drizzle/schema.ts" — `import { gelTable, uniqueIndex, uuid, smallint, text } from "drizzle-orm/gel-core"` … [source]
```typescript — `// ✅ Good: $files is declared in entities` … [source]
```ts — `import { i } from '@instantdb/react';` … [source]
```ts — `import { i } from '@instantdb/solidjs';` … [source]
```ts — `import { i } from '@instantdb/svelte';` … [source]
```ts — `import { i } from '@instantdb/vue';` … [source]
```typescript — `import { init, i } from '@instantdb/react';` … [source]
```typescript — `// instant.schema.ts` … [source]
```typescript — `// instant.schema.ts` … [source]
```js — `import { i } from '@instantdb/core';` … [source]
```javascript — `// instant.schema.ts` … [source]
```typescript — `// instant.schema.ts` … [source]
```javascript — `import { i } from "@instantdb/react";` … [source]
```javascript — `// instant.schema.ts` … [source]
```javascript — `import { i } from "@instantdb/react";` … [source]
```ts — `// instant.schema.ts` … [source]
```ts — `// src/instant.schema.ts` … [source]
db.<collection>.createIndex( { <field>: <value> }, { name: "<indexName>" } ) [source]
db.<collection>.createIndex( { <field>: "2dsphere" }, { "2dsphereIndexVersion": <version> } ) [source]
db.test.createIndex( { "address": "2dsphere" }, { "2dsphereIndexVersion": 2 } ) [source]
db.collection.createIndex( { "a": 1 }, { unique: true, sparse: true, expireAfterSeconds: 3600 } ) [source]
db.restaurants.createIndexes([{"borough": 1}, {"location": "2dsphere"}]) [source]
```prisma — `model User {` … [source]
```prisma no-lines — `@@unique(fields: [title, author])` … [source]
```prisma no-lines — `@@unique(fields: [title(length:10), author])` … [source]
```prisma — `model User {` … [source]
```prisma — `model Post {` … [source]
```prisma — `model Post {` … [source]
```prisma — `model categories {` … [source]
```prisma — `type Address {` … [source]
```prisma — `model Address {` … [source]
```sql theme={null} — `REINDEX;` … [source]
``` — `const user = await ctx.db` … [source]
``` — `// Use .withIndex() for efficient queries (preferred over .filter()):` … [source]
``` — `// ❌ -- potentially unbounded` … [source]
```ts — `import { boolean, integer, pgTable, serial, text, uniqueIndex, varchar } from "drizzle-orm/pg-core";` … [source]
db.inventory.find( { department: "kitchen", $text: { $search: "green" } } ).explain("executionStats") [source]
db.products.find( { quantity: { $gt: 50 }, category: "apparel" } ).explain("executionStats") [source]
db.inventory.find( { quantity: { $gte: 100, $lte: 200 } } ).explain("executionStats") [source]
db.inventory.find( { quantity: { $gte: 100, $lte: 300 }, type: "food" } ).hint({ quantity: 1, type: 1 }).explain("executionStats") [source]
db.inventory.find( { quantity: { $gte: 100, $lte: 300 }, type: "food" } ).hint({ type: 1, quantity: 1 }).explain("executionStats") [source]
```sql — `CREATE TABLE `Unique` (` … [source]
```prisma title="schema.prisma" showLineNumbers — `model Unique {` … [source]
```prisma title="schema.prisma" showLineNumbers — `model User {` … [source]
```sql theme={null} — `CREATE TABLE locations (` … [source]
```sql theme={null} — `PRAGMA index_list(table-name);` … [source]
```typescript — `// instant.schema.ts` … [source]
db.users.find().hint( { age: 1 } ) [source]
db.users.find().hint( "age_1" ) [source]
db.products.find( { _id: { $in: [ 6, 7 ] } } ).min( { price: Decimal128("1.39") } ).hint( { price: 1 } ) [source]
```prisma — `// Auto-incrementing integer: smallest and fastest to index,` … [source]
```ts — `// ❌ Causes implicit conversion` … [source]
```bash wrap — `With `relationMode = "prisma"`, no foreign keys are used, so relation fields will not benefit from the index u` … [source]
```ts — `import { getTableConfig, cockroachTable } from 'drizzle-orm/cockroach-core';` … [source]
```ts — `index().on(table.id, table.email) // will work well and name will be autogeneretaed` … [source]
<Section> — ````ts copy {7,8}` … [source]
```ts — `import { getTableConfig, mssqlTable } from 'drizzle-orm/mssql-core';` … [source]
```typescript {13-15} — `import * as p from 'drizzle-orm/mysql-core';` … [source]
```typescript {13-15} — `import * as p from "drizzle-orm/mysql-core";` … [source]
```typescript {26-28} — `import { defineRelations } from 'drizzle-orm';` … [source]
```ts — `import { getTableConfig, pgTable } from 'drizzle-orm/pg-core';` … [source]
```ts copy — `import { getTableConfig, singlestoreTable } from 'drizzle-orm/singlestore-core';` … [source]
```sql theme={null} — `-- Sort and remove duplicates` … [source]
``` — `tursodb> .indexes` … [source]
```sql theme={null} — `UPDATE table SET column[index] = value WHERE ...;` … [source]
```sql theme={null} — `CREATE TABLE articles (` … [source]
```sql theme={null} — `SELECT fts_highlight(title, '<b>', '</b>', 'database') AS highlighted` … [source]
``` — `data: {"id":"3f1c8a2e-9b14-4d6a-a7e2-0c5b8d1e4f90","object":"chat.completion.chunk","created":1715367049,"mode` … [source]
```typescript — `// ❌ Bad: Attribute must be indexed for comparison operators` … [source]
```typescript — `// ❌ Bad: Field must be indexed for ordering` … [source]
```javascript — `console.log(error);` … [source]
```typescript — `import { PlatformApi, i } from '@instantdb/platform';` … [source]
```ts — `// src/instant.schema.ts` … [source]
```typescript — `import { PlatformApi, i } from '@instantdb/platform';` … [source]
db.runCommand( { collMod: "apples", index: { keyPattern: { type: 1 }, unique: true }, dryRun: true } ) [source]
```prisma — `model User {` … [source]
```ts — `const result = await prisma.user.findUnique({` … [source]
```prisma — `model User {` … [source]
``` — `import { query } from "./_generated/server";` … [source]
``` — `import { query } from "./_generated/server";` … [source]
``` — `import { v } from "convex/values";` … [source]
``` — `export const enqueueAndListPending = mutation({` … [source]
``` — `export const listWithExtraArg = query({` … [source]
``` — `// We expect only one user with that email address.` … [source]
``` — `import { query } from "./_generated/server";` … [source]
``` — `import { query } from "./_generated/server";` … [source]
``` — `import { internalMutation } from "./_generated/server";` … [source]
``` — `// ❌ This looks through all the books, and then collects the ones authored by Jane Austen` … [source]
``` — `import { query } from "./_generated/server";` … [source]
``` — `// ❌` … [source]
``` — `// A Convex query function` … [source]
``` — `export const getAllOpenTasks = query({` … [source]
``` — `import { query } from "./_generated/server";` … [source]
db.<collection>.createIndex( { <field1>: <sortOrder>, <field2>: <sortOrder>, ... <fieldN>: <sortOrder> } ) [source]
db.addresses.createIndex( { borough: 1 }, { hidden: true } ); [source]
db.addresses.getIndexes() [source]
db.restaurants.createIndex( { borough: 1, ratings: 1 } ); [source]
db.restaurants.getIndexes() [source]
db.users.createIndex( { name: 1, email: 1, password: 1 }, { unique: true } ) [source]
db.users.createIndex( { "email": 1, "name": 1 }, { unique: true } ) [source]
db.users.createIndex( { email : 1 }, { name: "basic_index" } ) [source]
db.users.createIndex( { email : 1 }, { name: "unique_index", unique: true } ) [source]
db.collection.createIndex( { <field>: <sortOrder> }, { unique: true } ) [source]
db.members.createIndex( { "user_id": 1 }, { unique: true } ) [source]
db.collection.createIndex( { "$**": <sortOrder> } ) [source]
db.employees.createIndex( { "$**" : 1 } ) [source]
db.blog.createIndex( { content: "text", "users.comments": "text", "users.profiles": "text" }, { name: "InteractionsTextIndex" } ) [source]
db.<collection>.getIndexes() [source]
db.<collection>.createIndex( { <location field>: "2d" }, { min: <lower bound>, max: <upper bound> } ) [source]
db.contacts.createIndex( { address: "2d" }, { min: -75, max: 60 } ) [source]
db.places.createIndex( { "locs": "2d" } ) [source]
db.records.createIndex( { "addresses.loc": "2d" } ) [source]
db.survey.createIndex( { item: 1, ratings: 1 } ) [source]
db.<collection>.createIndex( { "$**": "text" } ) [source]
db.blog.createIndex( { "$**": "text" } ) [source]
db.inventory.createIndex( { department: 1, description: "text" } ) [source]
db.<collection>.createIndex( { <field>: "text" }, { "textIndexVersion": <version> } ) [source]
db.test.createIndex( { "content": "text" }, { "textIndexVersion": 2 } ) [source]
db.artwork.createIndex( { "$**" : 1 } ) [source]
db.<collection>.createIndex( { "$**" : <sortOrder> }, { "wildcardProjection" : { "<field1>" : < 0 | 1 >, "<field2>" : < 0 | 1 >, ... "<fieldN>" : < 0 | 1 > } } ) [source]
db.products.createIndex( { "$**" : 1 }, { "wildcardProjection" : { "attributes.size" : 1, "attributes.color" : 1 } } ) [source]
db.salesData.createIndex( { tenantId: 1, "customFields.$**": 1 }, { name: "tenant_customFields_shellHelper" } ) [source]
db.salesData.createIndex( { tenantId: 1, "$**": 1 }, { "wildcardProjection": { "customFields.addr": 1, "customFields.name": 1 }, name: "tenant_customFields_projection_helper" } ) [source]
db.salesData.dropIndex( "tenant_customFields" ) [source]
db.fleet.createIndex( { "ship.$**": 1 } ) [source]
db.books.createIndex( { "$**": 1 }, { wildcardProjection: { "author.name": 1, "author.website": 1 }, name: "authorWildcard" } ) [source]
db.books.createIndex( { "$**": 1 }, { wildcardProjection: { "publisher.name": 1 }, name: "publisherWildcard" } ) [source]
db.runCommand ( { listIndexes: "<collection-name>", cursor: { batchSize: <int> }, comment: <any> } ) [source]
db.products.createIndexes( [ { "item" : 1, "type" : 1 }, { "item" : 1, "type" : -1 }, { "price" : 1 } ] ) [source]
db.collection.createIndex( <keys>, <options>, <commitQuorum> ) [source]
db.movies.createIndex( { title: 1 }, { collation: { locale: "fr" } } ) [source]
db.movies.createIndex( { year: 1, metacritic: 1, title: 1 }, { collation: { locale: "fr" } } ) [source]
db.pets.createIndex( { cat: -1 }, { name: "catIdx" } ) [source]
db.pets.dropIndex( "catIdx" ) [source]
db.pets.dropIndex( { "cat" : -1 } ) [source]
db.inventory.createIndex( { quantity: 1, type: 1 } ) db.inventory.createIndex( { type: 1, quantity: 1 } ) [source]
db.movies.createIndex( { directors: 1, year: 1 } ) [source]
```sql theme={null} — `SELECT * FROM sqlite_stat1;` … [source]
```sql theme={null} — `EXPLAIN statement;` … [source]
```sql theme={null} — `EXPLAIN QUERY PLAN SELECT * FROM users WHERE name = 'Alice';` … [source]
```sql theme={null} — `EXPLAIN QUERY PLAN` … [source]
```sql theme={null} — `EXPLAIN QUERY PLAN` … [source]
db.runCommand( { reIndex: <collection> } ) [source]
db.movies.explain( "executionStats").find( { year: { $gt: 1990 }, rated: { $in: [ "PG", "PG-13" ] } } ) [source]

Measurements and reference values

In this example, the `status` of 99% of documents in the collection is `processed`. If you add an index on `status` and query for documents with the `status` of `processed`, both the index and the query have low selectivity. However, if you want to query for documents that do **not** have the `status` of `processed`, the index and the query have high selectivity because the query only returns 1% of the documents in a collection. [source]
| | Free/Starter | Professional | Business | Enterprise | Notes | | ----------------- | -------------------------------------------------------------------------------------- | -------------------------------------------------- | --------------------- [source]
The architecture supports vertical scaling for tenants and horizontal scaling across tenants. For vector embeddings, the total index size is divided into smaller chunks across multiple machines. Additionally, since the storage is in S3, Nile can swap a tenant’s embeddings entirely to S3 without maintaining a local cache. The indexes themselves are smaller, and multiple machines can be leveraged to build indexes in parallel. This approach provides lower latency and nearly 100% recall by reducing the search space per customer. [source]
With approximate indexes, filtering is applied after the index is scanned. If a condition matches 10% of rows, with HNSW and the default hnsw\.ef\_search of 40, only 4 rows will match on average. [source]
| | Free/Starter | Professional | Business | Enterprise | Notes | | -------------- | ------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------- | ------------------------- | ------------------------- | ---- [source]
AI workloads demand significantly more memory and compute than traditional SaaS workloads. Customer adoption and growth are much faster with AI, though some of this can be attributed to a hype cycle. Moreover, rebuilding indexes for embeddings requires additional resources and may impact production workloads. The ability to isolate customer data and their AI workloads has a significant impact on the customer's experience. Isolation is a key customer requirement (no one wants their data mixed with anyone else’s) and also critical to performance - 3 million embeddings is very large. 1000 tenants [source]
SQLite utilizes the virtual table [`dbstat`](https://www.sqlite.org/dbstat.html) to calculate the total space used by all tables and indexes. The base unit for this measurement is a database file page, which is 4KB. [source]
During function execution, new documents inserted with `db.vars.commitTs` will have the `CommitTsPlaceholder`. Resolved commit timestamps are Int64s (bigint in JS). You can use the `v.commitTs()` validator in argument and return validators and schema definitions. It accepts both resolved Int64 values and the commit timestamp placeholder. Fields with the commit timestamp are otherwise like any other field: they can be used in indexes, nested objects, arrays, and unions. [source]
| Metric | Description | |---|---| | Execution Count | Number of queries executed per hour which would be improved. | | Average Execution Time | Current average execution time in milliseconds for affected queries. | | Average Query Targeting | Average number of documents read per document returned by affected queries. A higher query targeting score indicates a greater degree of inefficiency. For more information on query targeting, see [Query Targeting.](https://www.mongodb.com#std-label-query-targeting) | | In Memory Sort | Current number of affected queries per hour that needed to be sorted [source]

Problems, failure modes and limitations

- If a hidden index is a [unique index](https://www.mongodb.com/docs/manual/core/index-unique/#std-label-index-type-unique) , the index still applies its unique constraint to the documents. - If a hidden index is a [TTL index](https://www.mongodb.com/docs/manual/core/index-ttl/#std-label-index-feature-ttl) , the index still expires documents. - Hidden indexes are included in [`listIndexes`](https://www.mongodb.com/docs/manual/reference/command/listIndexes/#mongodb-dbcommand-dbcmd.listIndexes) and[`db.collection.getIndexes()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.g [source]
- [`queryPlanner.winningPlan.queryPlan.stage`](https://www.mongodb.com/docs/manual/reference/explain-results/#mongodb-data-explain.queryPlanner.winningPlan.queryPlan.stage) displays`COLLSCAN` to indicate a collection scan.Collection scans indicate that the [`mongod`](https://www.mongodb.com/docs/manual/reference/program/mongod/#mongodb-binary-bin.mongod) had to scan the entire collection document by document to identify the results. This is a generally expensive operation and can result in slow queries. - [`executionStats.nReturned`](https://www.mongodb.com/docs/manual/reference/explain-result [source]
If a document has a `null` or missing value for the indexed field in a unique single-field index, the index stores a `null` value for that document. Because of the unique constraint, a single-field unique index can only contain one document that contains a `null` value in its index entry. If there is more than one document with a `null` value in its index entry, the index build fails with a duplicate key error. [source]
- When an [index filter](https://www.mongodb.com/docs/manual/core/query-plans/#std-label-index-filters) exists for the query shape, MongoDB ignores the[`hint()`.](https://www.mongodb.com#mongodb-method-cursor.hint) - If a query includes a `$text` expression, you cannot use[`hint()`](https://www.mongodb.com#mongodb-method-cursor.hint) to specify which index to use for the query. - If you use [`hint()`](https://www.mongodb.com#mongodb-method-cursor.hint) on a[hidden index](https://www.mongodb.com/docs/manual/core/index-hidden/) or an index that doesn't exist, the operation returns an error. - On [source]
* Corresponding database construct: `INDEX` * There are some additional index configuration options that cannot be provided via the Prisma schema yet. These include: * PostgreSQL and CockroachDB: * Define index fields as expressions (e.g. `CREATE INDEX title ON public."Post"((lower(title)) text_ops);`) * Create indexes concurrently with `CONCURRENTLY` [source]
| Parameter | Description | | ------------------------- | ------------------------------------------------------------------------------------------------------------------------------- | | `UNIQUE` | Enforces a uniqueness constraint. Turso rejects any INSERT or UPDATE that would create duplicate values in the indexed columns. | | `IF NOT EXISTS` | Prevents an error if an index with the same name already exists. The statement is a no-op [source]
- The Query Performance Summary shows the execution stats of the query: - Documents Returned displays `3` to indicate that the winning query plan returns three documents. - Index Keys Examined displays `0` to indicate that this query is not using an index. - Documents Examined displays `10` to indicate that MongoDB had to scan ten documents (i.e. all documents in the collection) to find the three matching documents. - Below the Query Performance Summary, MongoDB Compass displays the `COLLSCAN` query stage to indicate that a collection scan was used for this query.Collection scans indicate that [source]
* GIN indexes can be large, plan storage accordingly * Index creation might be slow for large tables * Index only necessary columns * Monitor index size and search performance * Adjust similarity threshold to balance precision and recall * Consider using `pg_bigm.enable_recheck` for better accuracy [source]
* GIN indexes provide faster search but slower updates * Index size can be large for text columns with many unique values * Consider partial indexes for large tables * Monitor and adjust similarity threshold based on false positive/negative rates [source]
| Condition | Error | | --------------------------------------------------------------------------------------- | ------------------------------------------------ | | The column is a PRIMARY KEY or part of one | Cannot drop PRIMARY KEY column | | The column has a UNIQUE constraint | Cannot drop UNIQUE column | | The column is referenced b [source]
Hidden indexes are not visible to the [query planner](https://www.mongodb.com/docs/manual/core/query-plans/) and cannot be used to support a query. [source]
- You can create multiple wildcard indexes in a collection. - A wildcard index can cover the same fields as other indexes in the collection. - Wildcard indexes omit the `_id` field by default. To include the`_id` field in the wildcard index, you must explicitly include it in the`wildcardProjection` document by specifying`{ "_id" : 1 }` . - Wildcard indexes are [sparse indexes](https://www.mongodb.com/docs/manual/core/index-sparse/#std-label-index-type-sparse) and only contain entries for documents that have the indexed field, even if the index field contains a null value. - Wildcard indexes ar [source]
When your query fetches documents from the database, it will scan the rows in the range you specify. If you are using `.collect()`, for instance, it will scan all of the rows in the range. So if you use `withIndex` without a range expression, you will be [scanning the whole table](https://docs.convex.dev/database/indexes/indexes-and-query-perf#full-table-scans), which can be slow when your table has thousands of rows. `.filter()` doesn't affect which documents are scanned. Using `.first()` or `.unique()` or `.take(n)` will only scan rows until it has enough documents. [source]
- The following fields in the `options` document are not available in Stable API V1: - `background` - `bucketSize` - `sparse` - `storageEngine` - [Text](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-text/#std-label-index-type-text) indexes are not available in Stable API V1. - The above unsupported index types are ignored by the [query planner](https://www.mongodb.com/docs/manual/core/query-plans/#std-label-query-plans-query-optimization) in[strict mode](https://www.mongodb.com/docs/manual/reference/stable-api/#std-label-stable-api-strict-client) . For example, attempting [source]
The `IGNORE INDEX` hint tells the optimizer to avoid using specific indexes for the query. MySQL will consider all other indexes (if any) or perform a full table scan if necessary. [source]
The `FORCE INDEX` hint forces the optimizer to use the specified index(es) for the query. If the specified index cannot be used, MySQL will not fall back to other indexes; it might resort to a full table scan instead. [source]
| Parameter | Description | | ------------- | ------------------------------------------------------------------------------------------------- | | `IF EXISTS` | Prevents an error if the index does not exist. The statement is a no-op when the index is absent. | | `schema-name` | The name of the attached database containing the index. Defaults to the main database if omitted. | | `index-name` | The name of the index to drop. | [source]
After `prepareUnique` is set, you cannot insert new documents that duplicate an index key entry. For example, the following insert operation results in an error: [source]
MongoDB cannot compound the index bounds and the `"ratings.scores.q2"` field is unconstrained during the index scan. [source]
The [`min()`](https://www.mongodb.com#mongodb-method-cursor.min) and [`max()`](https://www.mongodb.com/docs/manual/reference/method/cursor.max/#mongodb-method-cursor.max) methods indicate that the system should avoid normal query planning. They construct an index scan where the index bounds are explicitly specified by the values given in [`min()`](https://www.mongodb.com#mongodb-method-cursor.min) and `max()`. [source]
* Faster searches * Slower updates * Larger index size * Better for static data [source]
* Enforced by a [compound index in MongoDB](https://www.mongodb.com/docs/manual/core/index-compound/) * A `@@unique` block cannot be used as the only unique identifier for a model - MongoDB requires an `@id` field [source]
* Only explicitly created indexes can be dropped. Indexes automatically created for PRIMARY KEY and UNIQUE constraints cannot be dropped directly -- drop the table or use ALTER TABLE instead. * Dropping an index may degrade query performance for queries that relied on it, but does not affect correctness. [source]
For large tables, index backfill can be slow. Staging an index allows you to push the schema and enable the index later. [source]
If `staged` is `true`, the index will be staged and will not be enabled until the staged flag is removed. Staged indexes do not block push completion. Staged indexes cannot be used in queries. [source]
Wildcard indexes have restrictions including compound index limitations, incompatible properties, and specific shard key constraints. [source]
GIN and BTree are the only index types supported by CockroachDB. The operator classes marked to work with CockroachDB are the only ones allowed on that database and supported by Prisma ORM. The operator class cannot be defined in the Prisma Schema Language: the `ops` argument is not necessary or allowed on CockroachDB. [source]
- For a to-be-sharded collection, you cannot shard the collection if the collection has multiple unique indexes unless the shard key is the prefix for all the unique indexes. - For an already-sharded collection, you cannot create unique indexes on other fields unless the shard key is included as the prefix. - A unique index stores a null value for a document missing the indexed field; that is a missing index field is treated as another instance of a `null` index key value. For more information, see[Missing Document Field in a Unique Single-Field Index.](https://www.mongodb.com#std-label-unique [source]
- Index names must be unique. Creating an index with the name of an existing index returns an error. - You can't rename an existing index. Instead, you must [drop](https://www.mongodb.com/docs/manual/core/indexes/drop-index/#std-label-drop-an-index) and recreate the index with a new name. [source]
If the query does not join the conditions on the array field with `$elemMatch`, MongoDB cannot intersect the multikey index bounds. [source]
You cannot [drop](https://www.mongodb.com/docs/manual/reference/method/db.collection.dropIndex/#std-label-collection-drop-index) or [hide](https://www.mongodb.com/docs/manual/reference/method/db.collection.hideIndex/#std-label-collection-hide-index) an index if it is the only non-hidden index that supports the shard key. [source]
- `db.collection.dropIndex(index)`- Drops or removes the specified index from a collection. ## Note - You cannot drop the default index on the `_id` field. - You cannot specify [`db.collection.dropIndex("*")`](https://www.mongodb.com#mongodb-method-db.collection.dropIndex) to drop all non-`_id` indexes. Use[`db.collection.dropIndexes()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.dropIndexes/#mongodb-method-db.collection.dropIndexes) instead. To get the index name or the index specification document for the [`db.collection.dropIndex()`](https://www.mongodb.com#mongodb-m [source]
| Parameter | Type | Description | |---|---|---| | `index` | string or document | Required. Specifies the index to drop. You can specify the index either by the index name or by the index specification document. To drop a [text](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-text/#std-label-index-type-text) index, specify the index name. You cannot specify `"*"` to drop all non-`_id` indexes. Use[`db.collection.dropIndexes()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.dropIndexes/#mongodb-method-db.collection.dropIndexes) instead. If an index specif [source]
If you cannot stop all writes to the collection during this procedure, do not use the procedure on this page. Instead, build your unique index on the collection by issuing [`db.collection.createIndex()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.createIndex/#mongodb-method-db.collection.createIndex) on the primary for a replica set. [source]
- For building unique indexes - To create [unique indexes](https://www.mongodb.com/docs/manual/core/index-unique/#std-label-index-type-unique) using the following procedure, you must stop all writes to the collection during the index build. Otherwise, you may end up with inconsistent data across the replica set members.## WarningIf you cannot stop all writes to the collection, do not use the following procedure to create unique indexes. [source]
If you cannot stop all writes to the collection during this procedure, do not use the procedure on this page. Instead, build your unique index on the collection by issuing [`db.collection.createIndex()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.createIndex/#mongodb-method-db.collection.createIndex) on the [`mongos`](https://www.mongodb.com/docs/manual/reference/program/mongos/#mongodb-binary-bin.mongos) for a sharded cluster. [source]
When you insert `user1` without the `accounts.bank` and `accounts.number` fields, MongoDB sets them to `null` and adds a unique index entry. Any later insert that also lacks either field, such as `user2`, causes a duplicate key error. [source]
When you insert `account1` for the second time on the user, MongoDB does not create an index entry, so there are no duplicate values on it. To effectively implement your application design, your database should return an error if you attempt to add the same account multiple times to the same user. [source]
> [!WARNING] > For databases that don't enforce foreign keys (like PlanetScale), Prisma ORM emulates relations and you should manually add indexes on relation scalar fields to avoid full table scans: > > ```prisma title="prisma/schema.prisma" > model Comment { > postId Int > post Post @relation(fields: [postId], references: [id]) > > @@index([postId]) > } > ``` [source]
Decide whether they should be replaced with a `.withIndex` condition — per [this section](/understanding/best-practices/.md#only-use-collect-with-a-small-number-of-results), if you are filtering over a large (1000+) or potentially unbounded number of documents, you should use an index. If not using a `.withIndex` / `.withSearchIndex` condition, consider replacing them with a filter in code for more readability and flexibility. [source]
- To hide an index, you must have [featureCompatibilityVersion](https://www.mongodb.com/docs/manual/reference/command/setFeatureCompatibilityVersion/#std-label-view-fcv) set to`6.0` or greater. - You cannot hide the `_id` index. - You cannot [`cursor.hint()`](https://www.mongodb.com/docs/manual/reference/method/cursor.hint/#mongodb-method-cursor.hint) a hidden index. [source]
Analyzes and optimizes MongoDB query performance. This skill ensures queries are properly indexed, debugs slow queries using Atlas Performance Advisor, and provides best practice recommendations for aggregation pipelines. [source]
Note that in PostgreSQL, while you cannot specify sort order on unique constraints directly, you can create a unique index with a sort order that will enforce uniqueness: [source]
| Name | Type | Description [source]
MongoDB cannot create a [unique index](https://www.mongodb.com#std-label-index-type-unique) on the specified index field(s) if the collection already contains data that would violate the unique constraint for the index. [source]
You cannot specify a unique constraint on a [hashed index.](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-hashed/#std-label-index-type-hashed) [source]
In a small collection like the one used in the preceding example, there isn't a noticeable difference in performance between single-field and compound text indexes. However, in larger collections, increased index entry scans can noticeably hinder performance. For best performance, create text indexes that limit the number of index entries scanned to best fit your equality matches. [source]
The `ship.coordinates` field contains embedded arrays. Wildcard indexes do not record individual values of embedded arrays. Instead, they record the entire embedded array. As a result, the wildcard index cannot support a match on an embedded array value, and MongoDB fulfills the query with a collection scan. [source]
For document queries that return larger numbers of documents, you'll want to use an [index](/database/reading-data/indexes/.md) to improve the performance. Document queries that use indexes will be [ordered based on the columns in the index](/database/reading-data/indexes/.md#sorting-with-indexes) and can avoid slow table scans. [source]
This is okay, but we're still at risk of having a slow query because too many books have a title of *Foundation*. An even better approach could be to build a *compound* index that indexes both `author` and `title`. Compound indexes are indexes on an ordered list of fields. [source]
- You can't create indexes through the Performance Advisor if [Data Explorer](https://www.mongodb.com/docs/atlas/atlas-ui/#std-label-atlas-ui) is disabled for your project. You can still view the Performance Advisor recommendations, but you must create those indexes from[`mongosh`.](https://www.mongodb.com/docs/mongodb-shell/#mongodb-binary-bin.mongosh) - Atlas always creates indexes for entire clusters. If you create an index while viewing the Performance Advisor for a single shard in a sharded cluster, Atlas creates that index for the entire sharded cluster. [source]
If you filter by distance (recommended, to avoid nonsense results in case there aren't many similar vectors), it is recommended to use materialized CTE and place the filter outside the CTE in order to avoid overscanning: [source]
The Query Optimizer skill analyzes query performance, ensures proper indexing, and debugs slow queries using the Atlas Performance Advisor. [source]
- Create queries that your current indexes support to reduce the time needed to search for your results. - Avoid creating documents with large array fields that require a lot of processing to search and index. - Optimize your indexes and remove unused or inefficient indexes. Too many indexes can negatively impact write performance. - Consider the suggested indexes from the [Performance Advisor](https://www.mongodb.com/docs/atlas/performance-advisor/#std-label-performance-advisor) with the highest Impact scores and lowest Average Query Targeting scores. - Create the indexes that the Performance [source]
If you run `$text` queries on a large dataset, a single-field text index may scan a large number of entries to return results, which can result in slow queries. [source]
Since most databases have a length limit for entity names, the names will be trimmed if necessary to not violate the database limits. We will shorten the part before the `_suffix` as necessary so that the full name is at most the maximum length permitted. [source]
> [!WARNING] > Indexes using a function (such as `to_tsvector`) to determine the indexed value are not yet supported by Prisma ORM. Indexes defined in this way will not be visible with `prisma db pull`. [source]
> [!NOTE] > The object literal syntax validates field types. For example, you cannot use a `Boolean` value for a `String` field. For fields with types that are not supported by the object syntax (such as `Unsupported` or composite types), use `raw()` instead. [source]
MongoServerError: E11000 duplicate key error collection: test.apples index: type_1 dup key: { type: "Delicious" } [source]
The pattern `"$**"` includes all fields in the document. Use the `wildcardProjection` field to limit the index to fields you specify. For complete documentation on `wildcardProjection`, see [Options for `wildcard` indexes.](https://www.mongodb.com#std-label-createIndex-method-wildcard-option) [source]
If MongoDB cannot compound the two bounds, MongoDB constrains the index scan by the bound on the leading field. In this example, the leading field is `temperature`, resulting in a constraint of `temperature: [ [ 80, Infinity ] ]`. [source]
Merges all Tantivy segments into a single optimized segment. This improves query performance and reduces storage overhead, particularly after bulk inserts. [source]
Indexes like `by_foo` and `by_foo_and_bar` are usually redundant (you only need `by_foo_and_bar`). Reducing the number of indexes saves on database storage and reduces the overhead of writing to the table. Each index counts as another copy of the table's documents toward [database storage](/production/state/limits.md#database), so a table with three indexes uses about 4× its document size. [source]
Because views are virtual tables, they cannot have indexes. Therefore, `@index` and `@@index` cannot be defined on `view` blocks. [source]
The number of calls to `db.get` and `db.query` has a limit to prevent a single query from subscribing to too many index ranges, or a mutation from reading from too many ranges that could cause conflicts. [source]
These APIs allow you to efficiently limit your query to a reasonable size without performing a full table scan. [source]
If your Convex table has a small number of documents, this is fine! Full table scans should still be fast if there are a few hundred documents, but if the table has many thousands of documents these queries will become slow. [source]
* `CREATE INDEX` without `CONCURRENTLY` (blocks writes) * `ALTER COLUMN TYPE` (full table rewrite with `ACCESS EXCLUSIVE` lock) * `ADD COLUMN ... NOT NULL` without a safe default (blocks reads and writes) * Missing `lock_timeout` settings (risk of lock queue death spirals) [source]
| Risk level | Meaning | | ------------ | ----------------------------------------------------------------------------------------------------------------- | | **LOW** | Safe operations with minimal locking (e.g., `ADD COLUMN` with a constant default on PG 11+) | | **MEDIUM** | Operations that block writes but not reads (e.g., `CREATE INDEX` without `CONCURRENTLY`) | | **HIGH** | Operations that block writes and competing DDL, but [source]
pgfence will flag this as a `MEDIUM` risk because `CREATE INDEX` takes a `SHARE` lock, which blocks all writes to the table for the duration of the index build. It will suggest using `CREATE INDEX CONCURRENTLY` instead. [source]
> [!WARNING] > Prisma Migrate does not generate `CONCURRENTLY` variants automatically. If pgfence flags an index creation, you should manually edit the generated migration SQL file to add `CONCURRENTLY` before applying it. Note that `CREATE INDEX CONCURRENTLY` cannot run inside a transaction, so you will also need to ensure the migration runs outside a transaction block. [source]
pgfence can adjust risk levels based on actual table sizes. A `CREATE INDEX` on a 100-row table is very different from the same operation on a 10-million-row table. [source]
Index fields used in `where`, `orderBy`, and relations. Without indexes, the database can be forced to scan entire tables to find matching rows, which becomes slower as tables grow. [source]
SQL Server [allows only one `NULL` value per `UNIQUE` constraint](https://learn.microsoft.com/en-us/sql/relational-databases/tables/unique-constraints-and-check-constraints). Use filtered indexes to work around this, but note they cannot be used as foreign keys. [source]
Before running `prisma migrate deploy`, you can analyze your migration SQL files for potentially dangerous patterns using a migration safety tool like [pgfence](https://www.prisma.io/docs/guides/integrations/pgfence). pgfence detects operations that acquire heavy locks (such as `CREATE INDEX` without `CONCURRENTLY` or `ALTER COLUMN TYPE`), reports risk levels, and provides safe rewrite recipes. [source]
Patching or hotfixing a database involves making an often time critical change directly in production. For example, you might add an index directly to a production database to resolve an issue with a slow-running query. [source]
The `Hash` type will store the index data in a format that is much faster to search and insert, and that will use less disk space. However, only the `=` and `<>` comparisons can use the index, so other comparison operators such as `<` and `>` will be much slower with `Hash` than when using the default `BTree` type. [source]
> [!WARNING] > **CockroachDB limitation**: CockroachDB supports creating partial indexes, but it cannot introspect the predicate text from existing indexes. This means that after initial creation, modifications to the `where` clause (adding, changing, or removing a predicate) will not be detected by Prisma Migrate. The differ skips predicate comparison for CockroachDB to prevent false-positive migrations. [source]
<Callout type="warning"> Functional indexes are supported in MySQL starting from version `8.0.13`. For the correct syntax, the expression should be enclosed in parentheses, for example, `(lower(column))`. </Callout> [source]
* `CITEXT` is slightly **slower** than `TEXT` due to case normalization. * It does **not support LIKE queries** efficiently unless you create a functional index using `LOWER(column1)`. * Collation-sensitive operations may not always behave as expected. [source]
* **No subqueries in expressions**: The ENCODE, DECODE, and DEFAULT expressions cannot contain subqueries, aggregate functions, or window functions. * **No indexes on STRUCT/UNION columns**: CREATE INDEX on a STRUCT or UNION column is not supported. [source]
You may notice that the first deploy that defines an index is a bit slower than normal. This is because Convex needs to *backfill* your index. The more data in your table, the longer it will take Convex to organize it in index order. If you need to add indexes to large tables, use a [staged index](#staged-indexes). [source]
By default, index creation happens synchronously when you deploy code. For large tables, the process of [backfilling the index](/database/reading-data/indexes/indexes-and-query-perf.md#backfilling-and-maintaining-indexes) for the existing table can be slow. Staged indexes are a way to create an index on a large table asynchronously without blocking deploy. This can be useful if you are working on multiple features at once. [source]
Staged indexes cannot be used until enabled [source]
Staged indexes cannot be used in queries until you enable them. To enable them, they must first finish backfilling. [source]
No reserved fields (starting with `_`) are allowed in indexes. The `_creationTime` field is automatically added to the end of every index to ensure a stable ordering. It should not be added explicitly in the index definition, and it's counted towards the index fields limit. [source]
The same is true for Convex indexes! When you define a new index, the first time you run `npx convex deploy` Convex will need to loop through all of your documents and index each one. This is why the first deploy after the creation of a new index will be slightly slower than normal; Convex has to do a bit of work for each document in your table. If the table is particularly large, consider using a [staged index](/database/reading-data/indexes/.md#staged-indexes) to complete the backfill asynchronously from the deploy. [source]
* Table and index names must be valid identifiers and cannot start with an underscore. [source]
If you decide to continue with a rolling index, consider that they must meet certain conditions to succeed. To ensure your index build succeeds, avoid the following design patterns that commonly trigger a restart loop: [source]
For workloads which cannot tolerate performance decrease due to index builds, consider building indexes in a rolling fashion. [source]
Atlas automatically cancels rolling index builds that don't succeed on all nodes. When a rolling index build completes on some nodes, but fails on others, Atlas cancels the build and removes the index from any nodes that it was successfully built on. [source]
[Unique](https://www.mongodb.com/docs/manual/reference/method/db.collection.createIndex/#options-for-all-index-types) [index options](https://www.mongodb.com/docs/manual/reference/method/db.collection.createIndex/#options) are incompatible with building indexes in a rolling fashion. If you specify `unique` in the Options pane, Atlas rejects your configuration with an error message. [source]
For replica sets and sharded clusters, using a [rolling procedure](https://www.mongodb.com/docs/manual/tutorial/build-indexes-on-replica-sets/#std-label-index-build-on-replica-sets) to create a unique index requires that you stop all writes to the collection during the procedure. If you cannot stop all writes to the collection during the procedure, do not use the rolling procedure. Instead, to build your unique index on the collection you must either: [source]
Additionally, if there is a collation on the index key, you can only ensure uniqueness if the collation is simple. [source]
Using a 2d index for queries on spherical data can return incorrect results or an error. For example, 2d indexes don't support spherical queries that wrap around the poles. [source]
You cannot create a 2d index if your collection contains coordinate data outside of the index's location range. [source]
After you create a 2d index, you cannot insert a document that contains coordinate data outside of the index's location range. [source]
If your query specifies `$elemMatch` on fields that diverge from a common path, MongoDB **cannot** compound the bounds of index keys from the same array. [source]
Starting in MongoDB 6.0, [`dropIndexes`](https://www.mongodb.com#mongodb-dbcommand-dbcmd.dropIndexes) raises an error if you attempt to use it to remove the last remaining shard key compatible index. Passing `"*"` to [`dropIndexes`](https://www.mongodb.com#mongodb-dbcommand-dbcmd.dropIndexes) drops all indexes except the `_id` index and the last remaining shard key compatible index, if one exists. [source]
Starting in MongoDB 5.2, you can use [`dropIndexes`](https://www.mongodb.com#mongodb-dbcommand-dbcmd.dropIndexes) to drop existing indexes on the same collection even if there is a build in progress on another index. In earlier versions, attempting to drop a different index during an in-progress index build results in a `BackgroundOperationInProgressForNamespace` error. [source]
Multiple index options can be specified in the same document. However, if you specify multiple option documents the [`db.collection.createIndex()`](https://www.mongodb.com#mongodb-method-db.collection.createIndex) operation fails. [source]
| Parameter | Type | Description | |---|---|---| | `wildcardProjection` | document | Optional. Allows users to include or exclude specific field paths from a [wildcard index.](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-wildcard/#std-label-wildcard-index-core) This option is only valid when you create a [wildcard index](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-wildcard/#std-label-wildcard-index-core) on all document fields. You cannot specify the`wildcardProjection` option when you create a wildcard index on a specific field path and its subfiel [source]
Starting in MongoDB 7.1, index builds are improved with faster error reporting and increased failure resilience. You can also set the minimum available disk space required for index builds using the new [`indexBuildMinAvailableDiskSpaceMB`](https://www.mongodb.com/docs/manual/reference/parameters/#mongodb-parameter-param.indexBuildMinAvailableDiskSpaceMB) parameter, which stops index builds if disk space is too low. [source]
crash. A request to stop an index build is not always possible: if a member has already voted to commit the index, then the secondary cannot request that the index build stop and the secondary crashes (similar to MongoDB 7.0 and earlier). | An index build error can cause a secondary member to crash. | | Improved disk space management for index builds. An index build may be automatically stopped if the available disk space is below the minimum specified in the [`indexBuildMinAvailableDiskSpaceMB`](https://www.mongodb.com/docs/manual/reference/parameters/#mongodb-parameter-param.indexBuildMinAva [source]
er is any replica set member where[`members\[n\].votes`](https://www.mongodb.com/docs/manual/reference/replica-configuration/#mongodb-rsconf-rsconf.members-n-.votes) is greater than`0` . Supports the following values: `"votingMembers"` - all data-bearing voting replica set members (*Default* ). `"majority"` - a simple majority of data-bearing voting replica set members. `<int>` - a specific number of data-bearing voting replica set members. `0` - Disables quorum-voting behavior. Members start the index build simultaneously but do*not* vote or wait for quorum before completing the index build. [source]
[`db.collection.createIndexes()`](https://www.mongodb.com#mongodb-method-db.collection.createIndexes) will return an error if you attempt to create indexes with incompatible options or too many arguments. Refer to the option descriptions for more information. [source]
- When a user is creating an index with a `unique` key constraint and one shard contains a chunk with duplicate documents. In such cases, the create index operation may succeed on the shards without duplicates but not on the shard with duplicates. - When a user is creating an index across the shards in a rolling manner but either fails to build the index for an associated shard or incorrectly builds an index with different specification. [source]
"Range" filters scan fields. The scan doesn't require an exact match, which means range filters are loosely bound to index keys. To improve query efficiency, limit the range bounds and use equality matches to reduce the number of documents to scan. [source]
A single collection can have a maximum of 64 indexes. However, too many indexes can degrade performance before that limit is reached. For collections with a high write-to-read ratio, indexes can degrade performance because each insert must also update any indexes. [source] — MongoDB: 64 indexes per collection
- `reIndex`- *Deprecated since version 6.0.* :Attempting to run the [`reIndex`](https://www.mongodb.com#mongodb-dbcommand-dbcmd.reIndex) command writes a warning message to the log.## TipIn [`mongosh`](https://www.mongodb.com/docs/mongodb-shell/#std-program-mongosh) , this command can also be run through the[`db.collection.reIndex()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.reIndex/#mongodb-method-db.collection.reIndex) helper method.Helper methods are convenient for [`mongosh`](https://www.mongodb.com/docs/mongodb-shell/#std-program-mongosh) users, but they may not [source]
large number of indexes.## Warning - [`reIndex`](https://www.mongodb.com#mongodb-dbcommand-dbcmd.reIndex) may only be run on[standalone](https://www.mongodb.com/docs/manual/reference/glossary/#std-term-standalone) instances. - For most users, the [`reIndex`](https://www.mongodb.com#mongodb-dbcommand-dbcmd.reIndex) command is unnecessary. [source]
"Sort" determines the order for results. To avoid in-memory sorts, put sort fields before range in the index. [source]
Stored source fields can be defined in a search index to improve query performance and avoid full document lookups. [source]
If you do not add the index manually, queries might require full table scans. This can be slow, and also expensive on database providers that bill per accessed row. To help avoid this, Prisma ORM warns you when your schema contains fields that are used in a `@relation` that does not have an index defined. For example, take the following schema with a relation between the `User` and `Post` models: [source]
* Vector index works only for tables **with** `ROWID` or with singular `PRIMARY KEY`. Composite `PRIMARY KEY` without `ROWID` is not supported [source]
Search indexes work best with English or other Latin-script languages. Text is tokenized using Tantivy's [`SimpleTokenizer`](https://docs.rs/tantivy/latest/tantivy/tokenizer/struct.SimpleTokenizer.html), which splits on whitespace and punctuation. We also limit terms to 32 characters in length and lowercase them. [source]
Search indexes count against the [limit of 32 indexes per table](/database/reading-data/indexes/.md#limits). [source]
Vector indexes count towards the [limit of 32 indexes per table](/database/reading-data/indexes/.md#limits). In addition you can have up to 4 vector indexes per table. [source]
However, the following query operation, which by default uses the "simple" binary collator, cannot use the index and requires a `COLLSCAN`. [source]
The [Performance Advisor](https://www.mongodb.com/docs/atlas/performance-advisor/#std-label-performance-advisor) monitors queries that MongoDB considers slow and suggests new indexes to improve query performance. [source]
The Performance Advisor monitors queries that MongoDB considers slow and suggests new indexes to improve query performance. The threshold for slow queries varies based on the average time of operations on your cluster to provide recommendations pertinent to your workload. [source]
The Performance Advisor can't suggest indexes for MongoDB databases configured to use the `ctime` timestamp format. As a workaround, set the timestamp format for such databases to either `iso8601-utc` or `iso8601-local`. To learn more about timestamp formats, see [mongod --timeStampFormat.](https://www.mongodb.com/docs/manual/reference/program/mongod/#std-option-mongod.--timeStampFormat) [source]
Without the index, the query would scan the whole collection of `10` documents to return `3` matching documents. The query also had to scan the entirety of each document, potentially pulling them into memory. This results in an expensive and potentially slow query operation. [source]
| Method | Availability | Description | |---|---|---| | Use the Atlas Performance Advisor | M10+ Atlas clusters | The Atlas Performance Advisor monitors slow queries and suggests new indexes to improve performance. For more information, see [Monitor and Improve Slow Queries with the Performance Advisor.](https://www.mongodb.com/docs/atlas/performance-advisor/#std-label-performance-advisor) | | Check ongoing operations in Atlas | M10+ Atlas clusters | You can use the [Atlas Real-Time Performance Panel](https://www.mongodb.com/docs/atlas/real-time-performance-panel/#std-label-real-time-metrics-s [source]
The reason for this behavior is that all connectors consider `null` values to be distinct, which means that two rows that *look* identical are considered unique: [source]
CSFLE has limitations including unsupported operations on arrays, views, collation, indexes, and shard keys. [source]
Remove unnecessary indexes to optimize database performance and reduce maintenance overhead. [source]
"Cannot find a fulltext index to use for the search, try adding a @@fulltext(\[Fields...]) to your schema" [source]
`String` parameters in raw queries are encoded as `NVARCHAR(4000)` or `NVARCHAR(MAX)`. When querying `VARCHAR(N)` columns, manually cast to avoid index performance issues: [source]
This is not valid in MySQL because it exceeds MySQL's index storage limit and therefore Prisma ORM rejects the data model. The generated SQL would be rejected by the database. [source]
1. Hashing and encryption are CPU-intensive operations. Consider caching results when appropriate. 2. Encrypted columns cannot be effectively indexed. Consider indexing non-sensitive fields instead. [source]
* **No snippet function**: Use `fts_highlight` for term emphasis; context snippets are not yet available. * **No automatic segment merging**: Use `OPTIMIZE INDEX` periodically after bulk writes. * **No read-your-writes in a transaction**: FTS changes within a transaction are not visible to queries until the transaction is committed. ROLLBACK correctly discards both table and FTS changes. * **No MATCH operator syntax**: Use `fts_match()` function calls instead of `WHERE table MATCH 'query'`. [source]
Convex also supports a slower filtering mechanism that effectively loops through the table to match the filter. This can be useful if you know your table will be small (low thousands of rows), you're prototyping, or you want to filter an index query further. You can read more about filters [here](/database/reading-data/filters.md). [source]
Filters effectively loop over your table looking for documents that match. This can be slow or cause your function to hit a [limit](/production/state/limits.md) when your table has thousands of rows. For faster more database efficient queries use [indexes instead](/database/reading-data/indexes/.md). [source]
If a table has more than a few thousand documents, you should use [indexes](/database/reading-data/indexes/.md) to improve your document query performance. Otherwise, you may run into our enforced limits, detailed in [Read/write limit errors](/functions/error-handling/.md#readwrite-limit-errors). [source]
Convex supports indexes containing up to 16 fields. You can define 32 indexes on each table. Indexes can't contain duplicate fields. [source] — Convex: 32 indexes per table, 16 fields each
If you are defining a few indexes there is no need to worry about the maintenance cost. As you define more indexes, the cost to maintain them grows because every `insert` needs to update every index. This is why Convex has a limit of 32 indexes per table. In practice most applications define a handful of indexes per table to make their important queries efficient. [source]
In general, if you're running into these limits frequently, we recommend [indexing your queries](/database/reading-data/indexes/.md) to reduce the number of documents scanned, allowing you to avoid unnecessary reads. Queries that scan large swaths of your data may look innocent at first, but can easily blow up at any production scale. If your functions are close to hitting these limits they will log a warning. [source]
If there's a chance the number of results is large (say 1000+ documents), you should use an index to filter the results further before calling `.collect`, or find some other way to avoid loading all the documents such as using pagination, denormalizing data, or changing the product feature. [source]
- To hide an index, you must have [featureCompatibilityVersion](https://www.mongodb.com/docs/manual/reference/command/setFeatureCompatibilityVersion/#std-label-view-fcv) set to`6.0` or greater. - You cannot hide the `_id` index. [source]
MongoServerError: Cannot convert the index to unique. Please resolve conflicting documents before running collMod again. Violations: [ { ids: [ ObjectId("660489d24cabd75abebadbd0"), ObjectId("660489d24cabd75abebadbd2") ] } ] [source]
After you create the index, you cannot insert a document that contains coordinate data outside of the index's location range. For example, you **cannot** insert the following document: [source]
If you want to compare the shell commands and the database commands, you must drop the indexes between command invocations. You cannot create the same index twice, even with different names. [source]
You cannot drop the default index on the `_id` field. [source]
{ acknowledged: true, insertedId: 1 } MongoServerError: E11000 duplicate key error collection: test.users index: Unique Account dup key: { accounts.bank: null, accounts.number: null } [source]
{ acknowledged: true, insertedId: null, matchedCount: 1, modifiedCount: 1, upsertedCount: 0 } MongoServerError: E11000 duplicate key error collection: test.users index: Unique Account V2 dup key: { accounts.bank: "abc", accounts.number: "123" } [source]
The returned code shows that the database incorrectly adds the same account multiple times to the same user. This error occurs because MongoDB indexes do not duplicate strictly equal entries with the same key values pointing to the same document. [source]
Try replacing the call to `.filter()` with a call to `.withIndex()` if possible. This is especially important if the number of documents you’re filtering on is large (1000+) or unbounded. [source]
Explain output is limited by the maximum [Nested Depth for BSON Documents](https://www.mongodb.com/docs/manual/reference/limits/#mongodb-limit-Nested-Depth-for-BSON-Documents), which is 100 levels of nesting. Explain output that exceeds the limit is truncated. [source]

Comparisons and alternatives

The second compound index, `{ type: 1, quantity: 1 }`, is therefore the more efficient index for supporting the example query, as the MongoDB server only needs to scan `2` [`index keys`](https://www.mongodb.com/docs/manual/reference/explain-results/#mongodb-data-explain.executionStats.totalKeysExamined) to find all matching documents using this index, compared to `5` when when using the compound index `{ quantity: 1, type: 1 }`. [source]
- `COLLSCAN` - Indicates MongoDB performed a collection scan. - `IXSCAN` - Indicates MongoDB performed an index scan. - `FETCH` - Indicates MongoDB fetched full documents from the database. If the query returns a small number of fields and the application is not write intensive on this collection, consider adding indexes to cover the query. This allows MongoDB to fetch the field values from the index rather than reading the full document. For more information, see [Run Covered Queries.](https://www.mongodb.com/docs/manual/core/query-optimization/#std-label-covered-queries) - `PROJECTION` - Ind [source]
3. **Performance Considerations:** * GIN indexes are efficient for array-based queries but may have overhead during updates. * Consider the trade-off between query performance and update cost. * Regularly vacuum the GIN index to maintain performance. [source]
If one of the two boundaries is not specified, the query plan will be an index scan that is unbounded on one side. This may degrade performance compared to a query containing neither operator, or one that uses both operators to more tightly constrain the index scan. [source]
* GIN indexes are optimized for **fast lookups** but have **slower insert/update performance** compared to B-tree indexes. * They work best when querying multiple indexed columns together. * Unlike B-tree indexes, they **do not support range queries efficiently**. [source]
* GiST indexes generally **do not provide the same performance as B-tree indexes** for single-column lookups. * They **excel at multi-column queries** and range searches but can be **slower for simple equality lookups**. * `btree_gist` is useful primarily for **exclusion constraints** rather than improving query performance. [source]
1. **Structure**: * Hash indexes store only the hash value of the data being indexed. * No restrictions on the size of the indexed column. * Support only single-column indexes. * Do not allow uniqueness checking. 2. **Use Cases**: * Ideal for scenarios where exact matches are common. * Not suitable for range queries or pattern matching. 3. **Performance Considerations**: * Fast for equality lookups. * Minimal overhead during data insertion. * Not automatically maintained (unlike B-tree indexes). [source]
* GiST indexes are powerful but may have higher insertion and maintenance costs compared to B-tree indexes. * Choose the appropriate operator class and indexing strategy based on your data type and query requirements. [source]
* `@id` marks the primary key; `@@id([a, b])` declares a composite key. * `@unique` adds a unique constraint; `@@index([...])` declares a secondary index. * `@default(...)` sets a default. Database function defaults such as `@default(now())` become column defaults in the database. Generated defaults such as `@default(uuid())` are applied by Prisma 8 before each write instead, so they work the same on every database. They appear in the contract's `execution` section rather than as DDL. * `@map("column_name")` sets a field's physical name; `@@map("table_name")` sets the table or collection name [source]
From a syntax perspective, the vector index differs from ordinary application-defined B-Tree indices in that it must wrap the vector column into a `libsql_vector_idx` marker function like this [source]
A compound text index on the `department` and `description` fields limits the index keys scanned to only documents within the specified `department`. The compound text index provides improved performance compared to a single-field text index on the `description` field. [source]
**Best practice:** Use `.withIndex()` instead of `.filter()` for efficient queries. Define indexes in your schema for fields you query frequently. [source]
In Convex, you must explicitly use the `withIndex()` syntax to ensure your database uses the index. This differs from a more traditional SQL database, where the database implicitly chooses to use an index based on heuristics. The Convex approach leads to fewer surprises in the long run. [source] — Convex requires explicit withIndex; SQL planners pick indexes
An HNSW index creates a multilayer graph. It has slower build times and uses more memory than IVFFlat, but has better query performance (in terms of speed-recall tradeoff). There’s no training step like IVFFlat, so the index can be created without any data in the table. [source]
An IVFFlat index divides vectors into lists, and then searches a subset of those lists that are closest to the query vector. It has faster build times and uses less memory than HNSW, but has lower query performance (in terms of speed-recall tradeoff). [source]
* Bloom filters are probabilistic and can produce **false positives**, meaning they may return more results than expected. * They are best suited for queries filtering multiple indexed columns using **equality conditions** (`=`). * Unlike B-tree indexes, they **do not support range queries** (`<`, `>`, `BETWEEN`). [source]
* Indexes can be larger compared to traditional B-tree indexes * Not suitable for exact matching (use standard indexes instead) * May require more memory during search operations * Performance depends on similarity threshold and data size [source]
If your data is stored as longitude and latitude and you often run queries on spherical surfaces, use a [2dsphere index](https://www.mongodb.com/docs/manual/core/indexes/index-types/geospatial/2dsphere/#std-label-2dsphere-index) instead of a 2d index. [source]
Bloom indexes in PostgreSQL are useful for multi-column searches with high-cardinality data. They offer space efficiency but come with some trade-offs, such as potential false positives and lack of range query support. [source]
By hiding an index from the planner, you can evaluate the potential impact of dropping an index without actually dropping the index. If the impact is negative, you can unhide the index instead of having to recreate a dropped index. [source]
In addition, vector databases have indexes that can make searching large collections of vectors even more efficient. These indexes are different from those you are familiar with because they are based on machine learning algorithms. These algorithms find close vectors very efficiently, even with millions of vectors. But they have accuracy and memory use tradeoffs. Because of the accuracy tradeoffs (also known as **recall tradeoffs**, since it looks like the database “forgot” some of the data), the algorithms used in the indexes are called **ANN - approximate nearest neighbors** (as opposed to [source]
Keep in mind that vector indexes are unlike other database indexes. They are used to perform efficient **approximate** nearest neighbor searches. [source] — pgvector sense: approximate-nearest-neighbour index
When using vector indexes, you can control the trade-off between speed and recall by specifying the index type and parameters. [source]
Filtering in code instead of using the `.filter` syntax has the same performance, and is generally easier code to write. Conditions in `.withIndex` or `.withSearchIndex` are more efficient than `.filter` or filtering in code, so almost all uses of `.filter` should either be replaced with a `.withIndex` or `.withSearchIndex` condition, or written as TypeScript code. [source]
Indexes improve read performance, but a large number of indexes can negatively impact write performance since indexes must be updated during writes. If your collection already has several indexes, consider this tradeoff of read and write performance when deciding whether to create new indexes. Examine whether a query for such a collection can be modified to take advantage of existing indexes, as well as whether a query occurs often enough to justify the cost of a new index. [source]
If, however, the impact is negative, the user can unhide the index instead of having to recreate a dropped index. And because indexes are fully maintained while hidden, the indexes are immediately available for use once unhidden. [source]
In a larger dataset, the difference in query execution time between an indexed query versus a non-indexed query would be much more substantial. [source]
**Best practice:** Always include `args` and `returns` validators. Use `.withIndex()` instead of `.filter()` for efficient database queries. Queries should be fast since they run on every relevant data change. [source]
Using `.filter` on a paginated query (`.paginate`) has advantages over filtering in code. The paginated query will return the number of documents requested, including the `.filter` condition, so filtering in code afterwards can result in a smaller page or even an empty page. Using `.withIndex` on a paginated query will still be more efficient than a `.filter`. [source]
`cursor.explain()` defaults to `queryPlanner`, unlike the [`explain`](https://www.mongodb.com/docs/manual/reference/command/explain/#mongodb-dbcommand-dbcmd.explain) command, which defaults to `allPlansExecution`. [source]

Changes and history

| Behavior Starting in MongoDB 7.1 | Behavior in Earlier MongoDB Versions | |---|---| | Index errors found during the collection scan phase, except duplicate key errors, are returned immediately and then the index build stops. Earlier MongoDB versions return errors in the commit phase, which occurs near the end of the index build. MongoDB 7.1 helps you to rapidly diagnose index errors. For example, if an incompatible index value format is found, the error is returned to you immediately. | Index build errors can take a long time to be returned compared to MongoDB 7.1 because the errors are retu [source]
Version 3 text indexes are the current standard, supporting multiple languages via the `default_language` option. [source]

Facts and statements

* The [`type` argument](#configuring-the-access-type-of-indexes-with-type-postgresql) allows you to support index access methods other than PostgreSQL's default `BTree` access method * Available on the `@@index` attribute * PostgreSQL only * Supported index access methods: `Hash`, `Gist`, `Gin`, `SpGist` and `Brin` [source]
The `type` argument is available for configuring the index type in PostgreSQL with the `@@index` attribute. The index access methods available are `Hash`, `Gist`, `Gin`, `SpGist` and `Brin`, as well as the default `BTree` index access method. [source]
b-query-op.-or) operator [`$in`](https://www.mongodb.com/docs/manual/reference/operator/query/in/#mongodb-query-op.-in) operator [`$geoWithin`](https://www.mongodb.com/docs/manual/reference/operator/query/geoWithin/#mongodb-query-op.-geoWithin) operator [`$geoIntersects`](https://www.mongodb.com/docs/manual/reference/operator/query/geoIntersects/#mongodb-query-op.-geoIntersects) operator You can specify a `partialFilterExpression` option for all MongoDB[index types.](https://www.mongodb.com/docs/manual/core/indexes/index-types/#std-label-index-types) | | `sparse` | boolean | Optional. If `true [source]
ound index that includes `2dsphere` index keys and keys for other types, only the`2dsphere` index fields determine whether the index references a document. [Partial indexes](https://www.mongodb.com/docs/manual/core/index-partial/#std-label-index-type-partial) have a superset of the sparse index functionality. Unless your application has a specific requirement, use partial indexes instead of sparse indexes. | | `expireAfterSeconds` | integer | Optional. Specifies a value, in seconds, as a time to live ([TTL](https://www.mongodb.com/docs/manual/reference/glossary/#std-term-TTL) ) to control how [source]
* **BRIN** stands for **Block Range Index**. * Designed for handling very large tables with columns that have natural correlation to their physical location within the table. * Works in terms of **block ranges** (or "page ranges"). * Each block range groups physically adjacent pages in the table. * Summary information is stored by the index for each block range. * **Lossy**: BRIN indexes can satisfy queries via regular bitmap index scans but are lossy, meaning the query executor rechecks tuples and discards those not matching query conditions. * Size of block range determined at index creation [source]
| Detail Pattern | Meaning | | -------------------------------------------------- | ------------------------------------------------- | | `SCAN table` | Full table scan (no index used) | | `SEARCH table USING INDEX idx (col=?)` | Index lookup on the specified column | | `SEARCH table USING INTEGER PRIMARY KEY (rowid=?)` | Direct rowid lookup | | `USE TEMP B-TREE FOR ORDER BY` | A temporar [source]
| Index type (Algorithm) | Supported | Prisma schema | Prisma Client | Prisma Migrate | | ---------------------- | :-------: | :-----------: | :-----------: | :------------: | | B-tree | ✔️ | ✔️† | ✔️ | Not yet | | Hash | ✔️ | ✔️† | ✔️ | Not yet | | GiST | ✔️\* | ✔️† | ✔️\* | Not yet | | GIN | ✔️\* | ✔️† | ✔️\* | Not yet | | BRIN | ✔️\* | ✔️† | ✔️\* | [source]
| Parameter | Type | Description | |---|---|---| | `unique` | boolean | Optional. Specifies that each index specified in the `keyPatterns` array is a[unique index](https://www.mongodb.com/docs/manual/core/index-unique/#std-label-index-type-unique) . Unique indexes will not accept insertion or update of documents where the index key value matches an existing value in the index. Specify `true` to create a unique index. The default value is`false` . The option is *unavailable* for[hashed indexes.](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-hashed/#std-label-index-hashed-in [source]
* [DROP INDEX](/sql-reference/statements/drop-index) for removing indexes * [REINDEX](/sql-reference/statements/reindex) for rebuilding indexes * [CREATE TABLE](/sql-reference/statements/create-table) for inline UNIQUE and PRIMARY KEY constraints * [EXPLAIN](/sql-reference/statements/explain) for verifying index usage in query plans [source]
| Column | Type | Description | | ------- | ------- | --------------------------------------------------------------------- | | seq | INTEGER | Index sequence number | | name | TEXT | Index name | | unique | INTEGER | 1 if the index is UNIQUE | | origin | TEXT | `c` for CREATE INDEX, `u` for UNIQUE constraint, `pk` for PRIMARY KEY | | partial | INTEGER | 1 if the index [source]
4. **Query Using Index**: [source]
```sql theme={null} CREATE INDEX idx_location ON employees USING GIST (location); [source]
* To create a GIN index on the `skills` column: ```sql theme={null} CREATE INDEX idx_gin_skills ON employees USING gin(skills); ``` [source]
This example creates multiple indexes with the same key pattern and different `sparse` options: [source]
Let's create an example `employees` table and demonstrate Hash index usage: [source]
Let's create an employee table and demonstrate BRIN index usage. [source]
The unique index permits the insertion of the following document into the collection if no other document in the collection has an index key value of `{ "email": "[email protected]", "name": null }`. [source]
* **Length configuration** for MySQL indexes * **Sort order** configuration for indexes * **Additional index types** for PostgreSQL: * Hash * GIN * GiST * SP-GiST * BRIN * **Index clustering** for SQL Server [source]
A unique index ensures that the indexed fields do not store duplicate values, and that a value appears at most once for a given field. A unique compound index ensures that any given combination of the index key values appears at most once. By default, MongoDB creates a unique index on the [_id](https://www.mongodb.com/docs/manual/core/document/#std-label-document-id-field) field during the creation of a collection. [source]
Basic and unique indexes can exist with the same [key pattern.](https://www.mongodb.com/docs/manual/reference/method/db.collection.createIndexes/#std-label-key_patterns) [source]
- To learn how to create a multikey index on embedded document fields, see [Create an Index on an Embedded Field in an Array.](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-multikey/create-multikey-index-embedded/#std-label-index-create-multikey-embedded) - To learn about multikey index bounds, see [Multikey Index Bounds.](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-multikey/multikey-index-bounds/#std-label-indexes-multikey-bounds) [source]
- Compound wildcard indexes are sparse indexes. - Documents are included in the index if they are missing the wildcard field but have one of the compound fields. - Index fields, including wildcard fields, can be sorted in ascending ( `1` ) or descending (`-1` ) order. [source]
he following form: The `<value>` can be either of the following: `1` or`true` to include the field in the wildcard index. `0` or`false` to exclude the field from the wildcard index. Wildcard indexes omit the `_id` field by default. To include the`_id` field in the wildcard index, you must explicitly include it in the`wildcardProjection` document: All of the statements in the `wildcardProjection` document must be either inclusion or exclusion statements. You can also include the`_id` field with exclusion statements. This is the only exception to the rule. Options specified to [`db.collection.cr [source]
In most cases, applying the ESR (Equality, Sort, Range) Guideline to arrange the index keys creates a more efficient [compound index.](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-compound/#std-label-index-type-compound) [source]
* Corresponding database construct: `UNIQUE` * A `@@unique` block is required if it represents the only unique constraint on a model without an `@id` / `@@id` * Adding a unique constraint automatically adds a corresponding *unique index* to the specified column(s) [source]
1. By default Convex queries are *full table scans*. This is appropriate for prototyping and querying small tables. 2. As your tables grow larger, you can improve your query performance by adding *indexes*. Indexes are separate data structures that order your documents for fast querying. 3. In Convex, queries use the *`withIndex`* method to express the portion of the query that uses the index. The performance of a query is based on how many documents are in the index range expression. 4. Convex also supports *compound indexes* that index multiple fields. [source]
export const posts = pgTable( 'posts', { id: serial('id').primaryKey(), title: text('title').notNull(), body: text('body').notNull(), bodySearch: tsvector('body_search') .notNull() .generatedAlwaysAs((): SQL => sql`to_tsvector('english', ${posts.body})`), }, (t) => [ index('idx_body_search').using('gin', t.bodySearch), ] ); ``` </CodeTab> ```sql CREATE TABLE "posts" ( "id" serial PRIMARY KEY NOT NULL, "title" text NOT NULL, "body" text NOT NULL, "body_search" "tsvector" GENERATED ALWAYS AS (to_tsvector('english', "posts"."body")) STORED NOT NULL ); --> statement-breakpoint CREATE INDEX "idx_bo [source]
export const posts = pgTable( 'posts', { id: serial('id').primaryKey(), title: text('title').notNull(), body: text('body').notNull(), search: tsvector('search') .notNull() .generatedAlwaysAs( (): SQL => sql`setweight(to_tsvector('english', ${posts.title}), 'A') || setweight(to_tsvector('english', ${posts.body}), 'B')`, ), }, (t) => [ index('idx_search').using('gin', t.search), ], ); ``` </CodeTab> ```sql CREATE TABLE "posts" ( "id" serial PRIMARY KEY NOT NULL, "title" text NOT NULL, "body" text NOT NULL, "search" "tsvector" GENERATED ALWAYS AS (setweight(to_tsvector('english', "posts"."title") [source]
The number of index keys examined is indicated in the [`totalKeysExamined`](https://www.mongodb.com/docs/manual/reference/explain-results/#mongodb-data-explain.executionStats.totalKeysExamined) field. Queries that examine more index keys generally take longer to complete. [source]
MongoDB scanned `5` index keys ([`executionStats.totalKeysExamined`](https://www.mongodb.com/docs/manual/reference/explain-results/#mongodb-data-explain.executionStats.totalKeysExamined)) to return `2` matching documents ([`executionStats.nReturned`](https://www.mongodb.com/docs/manual/reference/explain-results/#mongodb-data-explain.executionStats.nReturned)). [source]
MongoDB scanned `2` index keys ([`executionStats.totalKeysExamined`](https://www.mongodb.com/docs/manual/reference/explain-results/#mongodb-data-explain.executionStats.totalKeysExamined)) to return `2` matching documents ([`executionStats.nReturned`](https://www.mongodb.com/docs/manual/reference/explain-results/#mongodb-data-explain.executionStats.nReturned)). [source]
If the number of keys examined is much lower than the number of documents examined, check each stage in the [`executionStages`](https://www.mongodb.com/docs/manual/reference/explain-results/#mongodb-data-explain.executionStats.executionStages) field, comparing the `keysExamined` and `docsExamined` to determine which stage failed to use the index. Then, [create an index](https://www.mongodb.com/docs/manual/core/indexes/create-index/#std-label-manual-create-an-index) to accommodate the query at that stage. [source]
The choice of index both affects how you write the index range expression and what order the results are returned in. For instance, by making both a `by_channel` and `by_channel_user` index, we can get results within a channel ordered by `_creationTime` or by `user`, respectively. If you were to use the `by_channel_user` index like this: [source]
1. 0 or more equality expressions defined with [`.eq`](/api/interfaces/server.IndexRangeBuilder.md#eq). 2. \[Optionally] A lower bound expression defined with [`.gt`](/api/interfaces/server.IndexRangeBuilder.md#gt) or [`.gte`](/api/interfaces/server.IndexRangeBuilder.md#gte). 3. \[Optionally] An upper bound expression defined with [`.lt`](/api/interfaces/server.IndexRangeBuilder.md#lt) or [`.lte`](/api/interfaces/server.IndexRangeBuilder.md#lte). [source]
Picking a good index range [source]
For performance, define index ranges that are as specific as possible! If you are querying a large table and you're unable to add any equality conditions with `.eq`, you should consider defining a new index. [source]
`.withIndex` is designed to only allow you to specify ranges that Convex can efficiently use your index to find. For all other filtering you can use the [`.filter`](/api/interfaces/server.Query.md#filter) method. [source]
* An index created for a table with existing data will be automatically populated with this data * All updates to the base table will be **automatically** reflected in the index * You can rebuild index from scratch using `REINDEX movies_idx` command * You can drop index with `DROP INDEX movies_idx` command * You can create [partial](https://www.sqlite.org/partialindex.html) vector index with a custom filtering rule: [source]
Wildcard indexes can support a [covered query](https://www.mongodb.com/docs/manual/core/query-optimization/#std-label-covered-queries) only if **all** of the following conditions are true: [source]
> **Note**: The `where` argument accepts either `raw("SQL expression")` for raw SQL predicates or an object literal like `{ field: value }` for type-safe conditions. See [Configuring partial indexes](https://www.prisma.io/docs/orm/v7/prisma-schema/data-model/indexes#configuring-partial-indexes-with-where) for details. [source]
| Name | Required | Type | Description | | ----------- | -------- | ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ [source]
Assume you want to add an index for the `title` field of the `Post` model [source]
The following schema defines three constraints (`@id`, `@unique`, and `@relation`) and one index (`@@index`): [source]
The following example adds custom names to one `@id` and the `@@index`: [source]
Additionally to `map`, the `@@id` and `@@unique` attributes take an optional `name` argument that allows you to customize your Prisma Client API. [source]
The `where` argument is available on the `@unique`, `@@unique` and `@@index` attributes. It requires the `partialIndexes` Preview feature. [source]
Builder to define an index range to query. [source]
**You must step through fields in index order.** [source]
Each equality expression must compare a different index field, starting from the beginning and in order. The upper and lower bounds must follow the equality expressions and compare the next field. [source]
This class is designed to only allow you to specify ranges that Convex can efficiently use your index to find. For all other filtering use [filter](/api/interfaces/server.OrderedQuery.md#filter). [source]
| Name | Type | Description | | ----------- | ----------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------- | | `fieldName` | `IndexFields`\[`FieldNum`] | The name of the field to compare. Must be the next field i [source]
| Name | Type | Description | | ----------- | ----------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | | `fieldName` | `Ind [source]
`DROP INDEX` removes a previously created index. After the index is dropped, the query planner can no longer use it to optimize queries. The table data is unchanged. [source]
The default operator class (marked with ✅) can be omitted from the index definition. [source]
Queries like `value = 2` will now use the index, which uses a fraction of the space used by the `BTree` or `Hash` indexes. [source]
Each index has its own configuration (GUC) for iterative scans: `hnsw.iterative_scan` and `ivfflat.iterative_scan`. By default both configurations are set to `off`. [source]
HNSW indexes support both relaxed and strict ordering for the iterative scans. Strict order guarantees that the returned results are ordered by exact distance. Relaxed order allows results that are slightly out of order, but provides better recall (i.e. fewer missed results due to the approximate nature of the index). [source]
A GiST index with `btree_gist` can be used for multi-column searches and exclusion constraints. Here's how to create one: [source]
* gin must be used as an index method. GiST is not available for pg\_bigm. * gin\_bigm\_ops must be used as an operator class. [source]
Hash indexes use a hash function to map indexed column values to 32-bit hash codes. These indexes are optimized for simple equality comparisons (using the `=` operator). Here's how they work: [source]
* **Purpose**: GiST indexes are designed to support various query types, including equality queries, range queries, and partial match queries. * **Infrastructure**: GiST provides an infrastructure within which different indexing strategies can be implemented. * [**Operator Classes**: The operators used with GiST indexes depend on the specific indexing strategy (operator class) chosen2](https://www.postgresql.org/docs/current/indexes-types.html). [source]
Let's explore some examples using tables related to employees. We'll create a sample table, insert data, and demonstrate how GiST indexes work. [source]
Suppose we have an `employees` table with a `location` column representing the employees' office locations (stored as geometric points). We want to efficiently query employees based on their proximity to a specific location. [source]
3. **Create GiST Index**: [source]
Let's create an example employee table and demonstrate how to use SP-GiST indexes. [source]
A partial index includes only the rows that satisfy the `WHERE` clause. Partial indexes are smaller than full indexes and are more efficient for queries that always include the same filter condition. [source]
The `WHERE` clause of a partial index can reference any column of the table and may use operators, literal values, and built-in functions. Subqueries are not allowed. [source]
Each expression in the index must be a deterministic expression that references only columns of the indexed table. Aggregate functions and subqueries are not allowed. [source]
<Info> **Turso Extension**: Custom index methods extend indexing beyond B-trees. This feature is experimental and must be [enabled before use](/sql-reference/experimental-features). </Info> [source]
`.index("by_foo", ["foo"])` is really an index on the properties `foo` and `_creationTime`, while `.index("by_foo_and_bar", ["foo", "bar"])` is an index on the properties `foo`, `bar`, and `_creationTime`. If you have queries that need to be sorted by `foo` and then `_creationTime`, then you need both indexes. [source]
For example, `.index("by_channel", ["channel"])` on a table of messages can be used to query for the most recent messages in a channel, but `.index("by_channel_and_author", ["channel", "author"])` could not be used for this since it would first sort the messages by `author`. [source]
The server uses the index the same way, but you may notice a difference in the output of the [`listIndexes`](https://www.mongodb.com#mongodb-dbcommand-dbcmd.listIndexes) and [`db.collection.getIndexes()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.getIndexes/#mongodb-method-db.collection.getIndexes) commands. [source]
The following example creates a compound index on the `year`, `runtime`, and `title` fields: [source]
The following example creates a compound index on the `title` field (in ascending order) and the `runtime` field (hashed): [source]
For more information on hashed indexes, see [Hashed Indexes.](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-hashed/#std-label-index-type-hashed) [source]
* Balanced performance between search and update * Smaller index size * Good for dynamic data [source]
<Step title="Create an Index"> Create an index using the `libsql_vector_idx` function: [source]
```sql theme={null} CREATE INDEX movies_idx ON movies(libsql_vector_idx(embedding)); ``` [source]
<Note> The `libsql_vector_idx` marker function is **required** and used by libSQL to distinguish `ANN`-indices from ordinary B-Tree indices. </Note> </Step> [source]
* [CREATE INDEX](/sql-reference/statements/create-index) for creating indexes * [DROP INDEX](/sql-reference/statements/drop-index) for removing indexes * [ANALYZE](/sql-reference/statements/analyze) for collecting index statistics [source]
Indexes speed up queries by allowing efficient lookups on specific fields. Use `.withIndex()` in your queries to leverage them. [source]
If you have a collection that has both a compound index and an index on its prefix (for example, `{ a: 1, b: 1 }` and `{ a: 1 }`), if neither index has a [sparse](https://www.mongodb.com/docs/manual/core/index-sparse/#std-label-index-type-sparse) or [unique](https://www.mongodb.com/docs/manual/core/index-unique/#std-label-index-type-unique) constraint, you can remove the index on the prefix (`{ a: 1 }`). MongoDB uses the compound index in all of the situations that it would have used the prefix index. [source]
MongoDB offers the ability to hide or unhide indexes from the query planner. By hiding an index from the planner, you can evaluate the potential impact of dropping an index without actually dropping the index. [source]
> **Note**: With the `partialIndexes` Preview feature, the `where` argument is available. Before this Preview feature, the signature was: > > ```prisma no-lines > @@index(_ fields: FieldReference[], map: String?) > ``` [source]
> [!NOTE] > Partial indexes are now supported in Prisma Schema Language via the `where` argument on `@@index`, `@@unique`, and `@unique`. See [Configuring partial indexes](https://www.prisma.io/docs/orm/v7/prisma-schema/data-model/indexes#configuring-partial-indexes-with-where) for details. You no longer need to customize migrations for partial indexes. > > The Prisma schema is also able to represent [unsupported field types](https://www.prisma.io/docs/orm/v7/prisma-schema/data-model/unsupported-database-features#unsupported-field-types) and [native database functions](https://www.prisma.io/do [source]
| Constraint or index | Follows convention | Underlying constraint or index names | | ---------------------------------- | ------------------ | ------------------------------------ | | `@id` (on `User` > `id` field) | Yes | `User_pk` | | `@@index` (on `Post`) | Yes | `Post_title_authorName_idx` | | `@id` (on `Post` > `id` field) | Yes | `Post_pk` | | `@relation` (on `Post` > `author`) | Yes | `Post_authorName_fkey` | [source]
| Constraint or index | Follows convention | Underlying constraint or index names | | ---------------------------------- | ------------------ | ------------------------------------ | | `@id` (on `User` > `id` field) | No | `Custom_Primary_Key_Constraint_Name` | | `@@index` (on `Post`) | No | `My_Custom_Index_Name` | | `@id` (on `Post` > `id` field) | Yes | `Post_pk` | | `@relation` (on `Post` > `author`) | Yes | `Post_authorName_fkey` | [source]
The `clustered` argument is available to configure (non)clustered indexes in SQL Server. It can be used on the `@id`, `@@id`, `@unique`, `@@unique` and `@@index` attributes. [source]
> [!NOTE] > Partial indexes are now supported in Prisma Schema Language via the `where` argument on `@@index`, `@@unique`, and `@unique`. See [Configuring partial indexes](https://www.prisma.io/docs/orm/v7/prisma-schema/data-model/indexes#configuring-partial-indexes-with-where) for details. [source]
| Entity | Convention | Example | | ----------------- | ------------------------------------ | ------------------------------ | | Primary Key | {tablename}_pkey | `User_pkey` | | Unique Constraint | {tablename}_{column_names}_key | `User_firstName_last_Name_key` | | Non-Unique Index | {tablename}_{column_names}_idx | `User_age_idx` | | Foreign Key | {tablename}_{column_names}_fkey | `User_childName_fkey` | [source]
`pg_bigm` supports full-text search indexes: [source]
The `fts` index method creates a full-text search index powered by Tantivy. FTS indexes support tokenizer configuration through the `WITH` clause. [source]
Index fields must be queried in the same order they are defined. If you need to query by `field2` then `field1`, create a separate index with that field order. [source]
**Best practice:** Always include all index fields in the index name (e.g., `"by_field1_and_field2"`). [source]
| Name | Type | | ---------------- | ---------------------------------------------- | | `IndexName` | extends `string` | | `FirstFieldPath` | extends `any` | | `RestFieldPaths` | extends `ExtractFieldPaths`<`DocumentType`>\[] | [source]
| Name | Type | Description | | -------- | ----------------------------------------- | --------------------------------------------------------------- | | `name` | `IndexName` | The name of the index. | | `fields` | \[`FirstFieldPath`, ...RestFieldPaths\[]] | The fields to index, in order. Must specify at least one field. | [source]
| Name | Type | | -------------- | ----------------------- | | `IndexName` | extends `string` | | `SearchField` | extends `any` | | `FilterFields` | extends `any` = `never` | [source]
| Name | Type | | -------------- | ----------------------- | | `IndexName` | extends `string` | | `VectorField` | extends `any` | | `FilterFields` | extends `any` = `never` | [source]
An object with parameters for performing a vector search against a vector index. [source]
4. \[Optional] A boolean `staged` flag  * If set to `true`, the index will be backfilled asynchronously from the deploy similar to [staged database indexes](/database/reading-data/indexes/.md#staged-indexes). This is useful for large tables where the index backfill time is significant. Defaults to `false`. [source]
The unique index prevents different documents in the collection from having the same value for the indexed key. [source]
For example, create a unique compound multikey index on `email` and `name`: [source]
MongoDB\Model\IndexInfo methods allow checking if an index is a 2dSphere, sparse, text, TTL, or unique index. [source]
Compound wildcard indexes combine wildcard terms with standard index terms to efficiently cover multiple queries with a single index. [source]
The GiST index type is used for implementing indexing schemes for user-defined types. By default there are not many direct uses for GiST indexes, but for example the B-Tree index type is built using a GiST index. [source]
export const stores = pgTable( 'stores', { id: serial('id').primaryKey(), name: text('name').notNull(), location: geometry('location', { type: 'point', mode: 'xy', srid: 4326 }).notNull(), }, (t) => [ index('spatial_index').using('gist', t.location), ] ); ``` </CodeTab> ```sql CREATE TABLE IF NOT EXISTS "stores" ( "id" serial PRIMARY KEY NOT NULL, "name" text NOT NULL, "location" geometry(point) NOT NULL ); --> statement-breakpoint CREATE INDEX IF NOT EXISTS "spatial_index" ON "stores" USING gist ("location"); ``` </CodeTabs> [source]
// custom lower function export function lower(email: AnyPgColumn): SQL { return sql`lower(${email})`; } ``` </CodeTab> ```sql CREATE TABLE IF NOT EXISTS "users" ( "id" serial PRIMARY KEY NOT NULL, "name" text NOT NULL, "email" text NOT NULL ); --> statement-breakpoint CREATE UNIQUE INDEX IF NOT EXISTS "emailUniqueIndex" ON "users" USING btree (lower("email")); ``` </CodeTabs> [source]
Enables GIN indexes to support B-tree indexable data types. [source]
The `btree_gin` extension enhances GIN indexes by allowing them to handle B-tree indexable data types efficiently. It is particularly useful for **multi-column indexing** scenarios where a mix of text, integer, and timestamp fields are queried together. [source]
Allows GiST indexes to support B-tree indexable data types. [source]
The [btree\_gist](https://www.postgresql.org/docs/current/btree-gist.html) extension in PostgreSQL allows GiST indexes to support B-tree indexable data types. It is useful for indexing columns that typically use B-tree indexes but require additional GiST-specific features such as **multicolumn indexing**, **range queries**, and **support for exclusion constraints**. Your Nile database arrives with `btree_gist` extension already enabled, so there's no need to run `create extension`. [source]
The `btree_gist` extension enhances GiST indexes by allowing them to handle B-tree indexable data types efficiently. It is particularly useful for **multi-column indexing**, **range queries**, and **exclusion constraints**. [source]
* GIN indexes are typically better for exact matches and contained-by queries * GiST indexes are better for overlap queries but may be less precise * Array operations are performed in memory, so be cautious with very large arrays * Sorting and uniqueness operations (`sort`, `uniq`) create new arrays [source]
<Card title="Btree_Gin" href="./btree_gin" icon="martini-glass-citrus"> GIN index support for B-tree indexable data types. </Card> [source]
<Card title="Btree_Gist" href="./btree_gist" icon="tree"> GiST index support for B-tree indexable data types. </Card> [source]
1. **Index Selection**: * Use GIN for mostly-read data * Use GiST for frequently updated data * Consider creating indexes only on frequently searched columns [source]
1. **Indexing**: Use GIN or BTREE indexes for frequent lookups by `tenant_id` and specific keys. 2. **Normalization**: Use `jsonb` for semi-structured data. For structured data, use regular columns and normalize the schema. 3. **Use UUID for `tenant_id`**: Ensure the `tenant_id` is a UUID to uniquely identify tenants, providing clear data isolation. [source]
1. Make sure that your mutations only read the data they need. Consider reducing the amount of data read by using indexed queries with [selective index range expressions](https://docs.convex.dev/database/indexes/). 2. Make sure you are not calling a mutation an unexpected number of times, perhaps from an action inside a loop. 3. Design your data model such that it doesn't require making many writes to the same document. [source]
Compound indexes collect and sort data from multiple field values from each document in a collection. You can use the compound index to query the first field or any prefix fields of the index. The order of fields in a compound index is very important. The B-tree created by a compound index stores the sorted data in the order that the index specifies the fields. [source]
- the index key specification document to the [`db.collection.hideIndex()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.hideIndex/#mongodb-method-db.collection.hideIndex) method:db.restaurants.hideIndex( { borough: 1, ratings: 1 } ); // Specify the index key specification document - the index name to the [`db.collection.hideIndex()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.hideIndex/#mongodb-method-db.collection.hideIndex) method:db.restaurants.hideIndex( "borough_1_ratings_1" ); // Specify the index name [source]
- the index key specification document to the [`db.collection.unhideIndex()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.unhideIndex/#mongodb-method-db.collection.unhideIndex) method:db.restaurants.unhideIndex( { borough: 1, city: 1 } ); // Specify the index key specification document - the index name to the [`db.collection.unhideIndex()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.unhideIndex/#mongodb-method-db.collection.unhideIndex) method:db.restaurants.unhideIndex( "borough_1_ratings_1" ); // Specify the index name [source]
Starting in MongoDB 5.0, [unique sparse](https://www.mongodb.com/docs/manual/core/index-sparse/#std-label-sparse-unique-index) and [unique non-sparse](https://www.mongodb.com/docs/manual/core/indexes/index-properties/#std-label-unique-index) indexes with the same [key pattern](https://www.mongodb.com/docs/manual/reference/method/db.collection.createIndexes/#std-label-key_patterns) can exist on a single collection. [source]
If the specified `lastName` is never an array, MongoDB can use the `$**` wildcard index to support a covered query. [source]
After you create the index, you can use the [`db.collection.getIndexes()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.getIndexes/#mongodb-method-db.collection.getIndexes) method to get the index name: [source]
Given an indexed array field, consider a query that specifies multiple query predicates on the array and uses a [multikey index](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-multikey/#std-label-index-type-multikey) to fulfill the query. MongoDB can intersect the multikey index bounds if an [`$elemMatch`](https://www.mongodb.com/docs/manual/reference/operator/query/elemMatch/#mongodb-query-op.-elemMatch) operator joins the query predicates. [source]
MongoDB supports creating wildcard indexes on a field or a set of fields. A compound index has multiple index terms. A compound wildcard index has one wildcard term and one or more additional index terms. [source]
The index key pattern is `"$**"`. You can create another wildcard index with the same key pattern if you specify a different `wildcardProjection`. For example: [source]
Although you can have a unique [compound index](https://www.mongodb.com/docs/manual/reference/glossary/#std-term-compound-index) where the shard key is a [prefix](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-compound/#std-label-compound-index-prefix), if using `unique` parameter, the collection must have a unique index that is on the shard key. [source]
If your application performs queries on both a single key and multiple keys, a [compound index](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-compound/#std-label-index-type-compound) is more efficient than a single-key index. For example, you can create an index on the `year`, `runtime`, and `title` fields: [source]
- To drop all non- `_id` indexes , specify`"*"` for the`index` .db.runCommand( { dropIndexes: "collection", index: "*" } ) - To drop a single index, issue the command by specifying the name of the index you want to drop. For example, to drop the index named `age_1` , use the following command:db.runCommand( { dropIndexes: "collection", index: "age_1" }) [`mongosh`](https://www.mongodb.com/docs/mongodb-shell/#mongodb-binary-bin.mongosh) provides the helper methods[`db.collection.dropIndex()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.dropIndex/#mongodb-method-db.collect [source]
- `listIndexes`- Returns information about the indexes on the specified collection, including [hidden indexes](https://www.mongodb.com/docs/manual/core/index-hidden/#std-label-index-type-hidden) and indexes that are currently being built. Returned index information includes the keys and options used to create the index. You can optionally set the batch size for the first batch of results.## TipIn [`mongosh`](https://www.mongodb.com/docs/mongodb-shell/#std-program-mongosh) , this command can also be run through the[`db.collection.getIndexes()`](https://www.mongodb.com/docs/manual/reference/meth [source]
If the options specification had been split into multiple documents like this: `{ unique: true }, { sparse: true, expireAfterSeconds: 3600 }` the index creation operation would have failed. [source]
If the `keys` document specifies more than one field, then [`createIndex()`](https://www.mongodb.com#mongodb-method-db.collection.createIndex) creates a [compound index.](https://www.mongodb.com/docs/manual/reference/glossary/#std-term-compound-index) [source]
ust be unique, you may only specify name if you are creating a single index using`db.collection.createIndexes()` . | | `partialFilterExpression` | document | Optional. If specified, the indexes only reference documents that match the filter expression. See [Partial Indexes](https://www.mongodb.com/docs/manual/core/index-partial/#std-label-index-type-partial) for more information. A filter expression can include: equality expressions (i.e. `field: value` or using the[`$eq`](https://www.mongodb.com/docs/manual/reference/operator/query/eq/#mongodb-query-op.-eq) operator) [`$exists: true`](https:/ [source]
[`db.collection.createIndex()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.createIndex/#mongodb-method-db.collection.createIndex) for examples of various index specifications. [source]
an array of index names: db.collection.dropIndexes( [ "a_1_b_1", "a_1", "a_1__id_-1" ] ) If the array of index names includes a non-existent index, the method errors without dropping any of the specified indexes. ## TipTo get the names of the indexes, use the [`db.collection.getIndexes()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.getIndexes/#mongodb-method-db.collection.getIndexes) method. [source]
- `db.collection.getIndexes()`- Returns an array that holds a list of documents that identify and describe the existing indexes on the collection, including [hidden indexes](https://www.mongodb.com/docs/manual/core/index-hidden/#std-label-index-type-hidden) and indexes that are currently being built.You must call [`db.collection.getIndexes()`](https://www.mongodb.com#mongodb-method-db.collection.getIndexes) on a collection. For example:db.collection.getIndexes() Change `collection` to the name of the collection for which to return index information. [source]
If you add an index on `status` and query for `{ "status": "pending", "product_type": "electronics" }`, MongoDB must read three index keys, retrieve three documents matching that status, and filter those documents further on `product_type` to return the one matching document. Similarly, a query for `{ "status": {$in: ["processed", "pending"] }, "product_type" : "electronics" }` must read six documents to return the two matching documents. [source]
db.collection.hideIndex() hides an existing index from the query planner to evaluate the impact of dropping an index without removing it. [source]
**3. Practical Examples:** Let's create an example `employees` table and demonstrate B-tree index usage: [source]
* [CREATE INDEX](/sql-reference/statements/create-index) for creating indexes * [EXPLAIN](/sql-reference/statements/explain) for examining query plans [source]
* [ANALYZE](/sql-reference/statements/analyze) for collecting statistics that improve query plans * [CREATE INDEX](/sql-reference/statements/create-index) for creating indexes to speed up queries [source]
| Form | Description | | ------------------------ | ---------------------------------------------------------- | | `REINDEX` | Rebuild all indexes in all attached databases | | `REINDEX collation-name` | Rebuild every index that uses the named collation sequence | | `REINDEX table-name` | Rebuild all indexes associated with the named table | | `REINDEX index-name` | Rebuild the named index | [source]
1. Full table scans: Queries created with [fullTableScan](/api/interfaces/server.QueryInitializer.md#fulltablescan) which iterate over all of the documents in the table in insertion order. 2. Indexed Queries: Queries created with [withIndex](/api/interfaces/server.QueryInitializer.md#withindex) which iterate over an index range in index order. [source]
](https://www.mongodb.com/docs/manual/reference/operator/aggregation/indexStats/#mongodb-pipeline-pipe.-indexStats) - Hiding an unhidden index or unhiding a hidden index resets its [`$indexStats`](https://www.mongodb.com/docs/manual/reference/operator/aggregation/indexStats/#mongodb-pipeline-pipe.-indexStats) . Hiding an already hidden index or unhiding an already unhidden index does not reset the[`$indexStats`.](https://www.mongodb.com/docs/manual/reference/operator/aggregation/indexStats/#mongodb-pipeline-pipe.-indexStats) [source]
- The query planner selects the wildcard index to fulfill the query predicate. - The query predicate specifies *exactly* one field covered by the wildcard index. - The query projection explicitly excludes `_id` and includes*only* the query field. - The specified query field is never an array. [source]
If you query for `{ "status": 2, "product_type": "grocery" }`, MongoDB only reads one document matching the index key, indicating the index is highly selective. By using this index, you can receive a query response more efficiently, since MongoDB must only further filter one document matching the index value. In this case, the filter also matches, and the query only returns one document. [source]
Although this example's query on `status` equality is more selective, a query such as `{ "status": { $gt: 5 }, "product_type": "grocery" }` still needs to read four documents if you use the same index on `status`. However, if you create a compound index on `product_type` and `status`, MongoDB can more efficiently answer a query for `{"status": { $gt: 5 }, "product_type": "grocery" }` via the compound index, as the query returns only one matching document. [source]
iagnostic logs.](https://www.mongodb.com/docs/manual/reference/log-messages/#std-label-log-messages-ref) Check the diagnostic logs to identify problematic queries and see which queries would benefit from indexes. | | View explain results | Atlas clusters and self-hosted deployments | Query explain results show information on the query plan and execution statistics. You can use explain results to determine the following information about a query: The amount of time a query took to execute Whether the query used an index The number of documents and index keys scanned to fulfill a query To view e [source]
A [TableDefinition](/api/classes/server.TableDefinition.md) with this search index included. [source]
The library supports various index types including single field, compound, multikey, text, and MongoDB Search indexes. [source]
The query planner selects and caches efficient query plans using available indexes, with specific states for plan cache management. [source]
* Corresponding database construct: `UNIQUE` * `NULL` values are considered to be distinct (multiple rows with `NULL` values in the same column are allowed) * Adding a unique constraint automatically adds a corresponding *unique index* to the specified column(s). [source]
In relational databases that use foreign key constraints, the database usually also implicitly creates an index for the foreign key columns. For example, [MySQL will create an index on all foreign key columns](https://dev.mysql.com/doc/refman/8.0/en/constraint-foreign-key.html#:~\:text=MySQL%20requires%20that%20foreign%20key%20columns%20be%20indexed%3B%20if%20you%20create%20a%20table%20with%20a%20foreign%20key%20constraint%20but%20no%20index%20on%20a%20given%20column%2C%20an%20index%20is%20created.). This is to allow foreign key checks to run fast and not require a table scan. [source]
export const test = cockroachTable( "test", { id: int4("id").primaryKey().generatedAlwaysAsIdentity(), content: string("content"), contentSearch: tsVector("content_search", { dimensions: 3, }).generatedAlwaysAs( (): SQL => sql`to_tsvector('english', ${test.content})` ), }, (t) => [ index("idx_content_search").using("gin", t.contentSearch) ] ); ``` ```sql {4} CREATE TABLE "test" ( "id" int4 PRIMARY KEY GENERATED ALWAYS AS IDENTITY (INCREMENT BY 1 MINVALUE 1 MAXVALUE 2147483647 START WITH 1 CACHE 1), "content" string, "content_search" tsvector GENERATED ALWAYS AS (to_tsvector('english', "test"." [source]
As for now, Drizzle doesn't support `tsvector` type natively, so you need to convert your data in the `text` column on the fly. To enhance the performance, you can create a `GIN` index on your column like this: [source]
export const guides = pgTable( 'guides', { id: serial('id').primaryKey(), title: text('title').notNull(), description: text('description').notNull(), url: text('url').notNull(), embedding: vector('embedding', { dimensions: 1536 }), }, (table) => [ index('embeddingIndex').using('hnsw', table.embedding.op('vector_cosine_ops')), ] ); ``` </CodeTab> ```sql CREATE TABLE IF NOT EXISTS "guides" ( "id" serial PRIMARY KEY NOT NULL, "title" text NOT NULL, "description" text NOT NULL, "url" text NOT NULL, "embedding" vector(1536) ); --> statement-breakpoint CREATE INDEX IF NOT EXISTS "embeddingIndex" ON [source]
That is why Drizzle always treats any `.unique()` as `UNIQUE INDEX` [source]
export const test = pgTable( "test", { id: integer("id").primaryKey().generatedAlwaysAsIdentity(), content: text("content"), contentSearch: tsVector("content_search", { dimensions: 3, }).generatedAlwaysAs( (): SQL => sql`to_tsvector('english', ${test.content})` ), }, (t) => [ index("idx_content_search").using("gin", t.contentSearch) ] ); ``` ```sql {4} CREATE TABLE "test" ( "id" integer PRIMARY KEY GENERATED ALWAYS AS IDENTITY (sequence name "test_id_seq" INCREMENT BY 1 MINVALUE 1 MAXVALUE 2147483647 START WITH 1 CACHE 1), "content" text, "content_search" tsvector GENERATED ALWAYS AS (to_tsvec [source]
* Create a table with one or more vector columns (e.g. `FLOAT32`) * Provide vector values in binary format or convert text representation to binary using the appropriate conversion function (e.g. `vector32(...)`) * Calculate vector similarity between vectors in the table or from the query itself using dedicated vector functions (e.g. `vector_distance_cos`) * Create a special vector index to speed up nearest neighbors queries (use the `libsql_vector_idx(column)` expression in the `CREATE INDEX` statement to create vector index) * Query the index with the special `vector_top_k(idx_name, q_vector [source]
At the moment vector index must be queried **explicitly** with special `vector_top_k(idx_name, q_vector, k)` [table-valued function](https://www.sqlite.org/vtab.html#table_valued_functions). The function accepts index name, query vector and amount of neighbors to return. This function searches for `k` approximate nearest neighbors and returns `ROWID` of these rows or `PRIMARY KEY` if base index [does not have ROWID](https://www.sqlite.org/withoutrowid.html). [source]
```text 200 theme={null} PRAGMA foreign_keys=OFF; BEGIN TRANSACTION; CREATE TABLE IF NOT EXISTS mytable ( content TEXT, embedding FLOAT32(1536) ); CREATE TABLE IF NOT EXISTS libsql_vector_index (type TEXT, name TEXT, vector_type TEXT, block_size INTEGER, dims INTEGER, distance_ops TEXT); INSERT INTO libsql_vector_index VALUES('diskann','mytable_idx','float32',128,1536,'cosine'); CREATE INDEX mytable_idx USING diskann_cosine_ops ON mytable (embedding); COMMIT; ``` </CodeGroup> [source]
| Flag | Description | | ---------------------------------------- | ----------------------------------------------------------------------------------- | | `--experimental-views` | Enable views (`CREATE VIEW` / `CREATE MATERIALIZED VIEW`) | | `--experimental-custom-types` | Enable custom types (`CREATE TYPE` / `DROP TYPE` / `CREATE DOMAIN` / `DROP DOMAIN`) | | `--experimental-encryption` | Enable at-rest database encrypt [source]
<Info> Sparse vectors can be indexed with the experimental sparse vector index method (enable `--experimental-index-method`). See [CREATE INDEX](/sql-reference/statements/create-index). </Info> [source]
▸ **index**<`IndexName`, `FirstFieldPath`, `RestFieldPaths`>(`name`, `indexConfig`): [`TableDefinition`](/api/classes/server.TableDefinition.md)<`DocumentType`, [`Expand`](/api/modules/server.md#expand)<`Indexes` & `Record`<`IndexName`, \[`FirstFieldPath`, ...RestFieldPaths\[], `"_creationTime"`]>>, `SearchIndexes`, `VectorIndexes`> [source]
[`TableDefinition`](/api/classes/server.TableDefinition.md)<`DocumentType`, [`Expand`](/api/modules/server.md#expand)<`Indexes` & `Record`<`IndexName`, \[`FirstFieldPath`, ...RestFieldPaths\[], `"_creationTime"`]>>, `SearchIndexes`, `VectorIndexes`> [source]
▸ **index**<`IndexName`, `FirstFieldPath`, `RestFieldPaths`>(`name`, `fields`): [`TableDefinition`](/api/classes/server.TableDefinition.md)<`DocumentType`, [`Expand`](/api/modules/server.md#expand)<`Indexes` & `Record`<`IndexName`, \[`FirstFieldPath`, ...RestFieldPaths\[], `"_creationTime"`]>>, `SearchIndexes`, `VectorIndexes`> [source]
▸ **index**<`IndexName`, `FirstFieldPath`, `RestFieldPaths`>(`name`, `indexConfig`): [`TableDefinition`](/api/classes/server.TableDefinition.md)<`DocumentType`, `Indexes`, `SearchIndexes`, `VectorIndexes`> [source]
▸ **searchIndex**<`IndexName`, `SearchField`, `FilterFields`>(`name`, `indexConfig`): [`TableDefinition`](/api/classes/server.TableDefinition.md)<`DocumentType`, `Indexes`, [`Expand`](/api/modules/server.md#expand)<`SearchIndexes` & `Record`<`IndexName`, { `searchField`: `SearchField` ; `filterFields`: `FilterFields` }>>, `VectorIndexes`> [source]
[`TableDefinition`](/api/classes/server.TableDefinition.md)<`DocumentType`, `Indexes`, [`Expand`](/api/modules/server.md#expand)<`SearchIndexes` & `Record`<`IndexName`, { `searchField`: `SearchField` ; `filterFields`: `FilterFields` }>>, `VectorIndexes`> [source]
▸ **searchIndex**<`IndexName`, `SearchField`, `FilterFields`>(`name`, `indexConfig`): [`TableDefinition`](/api/classes/server.TableDefinition.md)<`DocumentType`, `Indexes`, `SearchIndexes`, `VectorIndexes`> [source]
▸ **vectorIndex**<`IndexName`, `VectorField`, `FilterFields`>(`name`, `indexConfig`): [`TableDefinition`](/api/classes/server.TableDefinition.md)<`DocumentType`, `Indexes`, `SearchIndexes`, [`Expand`](/api/modules/server.md#expand)<`VectorIndexes` & `Record`<`IndexName`, { `vectorField`: `VectorField` ; `dimensions`: `number` ; `filterFields`: `FilterFields` }>>> [source]
[`TableDefinition`](/api/classes/server.TableDefinition.md)<`DocumentType`, `Indexes`, `SearchIndexes`, [`Expand`](/api/modules/server.md#expand)<`VectorIndexes` & `Record`<`IndexName`, { `vectorField`: `VectorField` ; `dimensions`: `number` ; `filterFields`: `FilterFields` }>>> [source]
▸ **vectorIndex**<`IndexName`, `VectorField`, `FilterFields`>(`name`, `indexConfig`): [`TableDefinition`](/api/classes/server.TableDefinition.md)<`DocumentType`, `Indexes`, `SearchIndexes`, `VectorIndexes`> [source]
| Name | Type | Description | | -------------- | -------------------------------- [source]
This will be an object mapping index names to the search index config. [source]
This will be an object mapping index names to the vector index config. [source]
1. `vectorField` string  * The name of the field indexed for vector search. 2. `dimensions` number  * The fixed size of the vectors index. If you're using embeddings, this dimension should match the size of your embeddings (e.g. `1536` for OpenAI). 3. \[Optional] `filterFields` array  * The names of additional fields that are indexed for fast filtering within your vector index. 4. \[Optional] `staged` boolean  * If set to `true`, the index will be backfilled asynchronously from the deploy similar to [staged database indexes](/database/reading-data/indexes/.md#st [source]
If you use both the `partialFilterExpression` and a unique constraint, the unique constraint only applies to documents that meet the filter expression. For an example, see [Partial Index with Unique Constraint.](https://www.mongodb.com/docs/manual/core/index-partial/#std-label-partial-index-with-unique-constraints) [source]
Wildcard text indexes are distinct from [wildcard indexes](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-wildcard/#std-label-wildcard-index-core). Wildcard text indexes support queries that use the [`$text`](https://www.mongodb.com/docs/manual/reference/operator/query/text/#mongodb-query-op.-text) operator, while wildcard indexes do not. [source]
Text indexes tokenize and stem the terms in the indexed fields for the index entries. The index uses simple [language-specific](https://www.mongodb.com#std-label-text-index-supported-languages) suffix stemming. For each document in the collection, the text index stores one index entry for each unique stemmed term in each indexed field. [source]
If an existing or newly inserted document lacks a text index field (or the field is null or an empty array), MongoDB does not add a text index entry for the document. [source]
For data hosted on MongoDB, you can support full-text search with MongoDB Search indexes. To learn more, see [Create a MongoDB Search Index.](https://www.mongodb.com/docs/atlas/atlas-search/create-index/) [source]
Vector Search Indexes support queries on vector embeddings. To create Vector Search Indexes, see [Index Fields for Vector Search.](https://www.mongodb.com/docs/atlas/atlas-vector-search/vector-search-type/) [source]
`listIndexes` does not return information on [MongoDB Search indexes](https://www.mongodb.com/docs/atlas/atlas-search/atlas-search-overview/#fts-indexes). Instead, use `$listSearchIndexes`. [source]
rforming the query. Specify the index either by the index name or by the index specification document. You can also specify `{ $natural : 1 }` to force the query to perform a forwards collection scan, or`{ $natural : -1 }` for a reverse collection scan. [source]
The [`cursor.explain("executionStats")`](https://www.mongodb.com/docs/manual/reference/method/cursor.explain/#mongodb-method-cursor.explain) and the [`db.collection.explain("executionStats")`](https://www.mongodb.com/docs/manual/reference/method/db.collection.explain/#mongodb-method-db.collection.explain) methods provide statistics about the performance of a query. These statistics can be useful in measuring if and how a query uses an index. See [`db.collection.explain()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.explain/#mongodb-method-db.collection.explain) for deta [source]
{ queryPlanner: { ... winningPlan: { queryPlan: { stage: 'FETCH', inputStage: { stage: 'IXSCAN', keyPattern: { quantity: 1 }, ... } } }, rejectedPlans: [ ] }, executionStats: { executionSuccess: true, nReturned: 3, executionTimeMillis: 0, totalKeysExamined: 3, totalDocsExamined: 3, executionStages: { ... }, ... }, ... } [source]
{ queryPlanner: { ... winningPlan: { queryPlan: { stage: 'FETCH', inputStage: { stage: 'IXSCAN', keyPattern: { quantity: 1, type: 1 }, ... } } } }, rejectedPlans: [ ] }, executionStats: { executionSuccess: true, nReturned: 2, executionTimeMillis: 0, totalKeysExamined: 5, totalDocsExamined: 2, executionStages: { ... } }, ... } [source]
{ queryPlanner: { ... queryPlan: { winningPlan: { stage: 'FETCH', inputStage: { stage: 'IXSCAN', keyPattern: { type: 1, quantity: 1 }, ... } } }, rejectedPlans: [ ] }, executionStats: { executionSuccess: true, nReturned: 2, executionTimeMillis: 0, totalKeysExamined: 2, totalDocsExamined: 2, executionStages: { ... } }, ... } [source]
Utilize the [`EXPLAIN QUERY PLAN`](https://www.sqlite.org/eqp.html) statement to gain insights into your query's execution plan. This tool is invaluable for identifying whether your query is performing a full table scan and if it's leveraging the most efficient index to reduce unnecessary reads. [source]
* Over-fetching data * Missing indexes * Not caching repeated queries * Full table scans [source]
HSNW has a configuration that controls the total number of rows that will be scanned by a query across all iterations (20,000 is the default): [source]
A query for "messages in `channel` created 1-2 minutes ago" over the `by_channel` index would look like: [source]
In this case the performance of this query will be based on how many messages are in the channel. Convex will consider each message in the channel and only return the messages where the `user` field doesn't match `myUserId`. [source]
Prisma ORM allows configuration of database indexes, unique constraints and primary key constraints. Full text indexes in MySQL and MongoDB are available through the `fullTextIndex` preview feature using the `@@fulltext` attribute. [source]
* `topic`: `"current_storage_usage"` * `timestamp`: Unix epoch timestamp in milliseconds * `total_document_size_bytes`: number, total size in bytes of all documents stored in database tables * `total_index_size_bytes`: number, total size in bytes of all database indexes * `total_vector_storage_bytes`: number, total size in bytes of vector index storage * `total_text_storage_bytes`: number, total size in bytes of text index storage * `total_file_storage_bytes`: number, total size in bytes of file storage * `total_backup_storage_bytes`: number, total size in bytes of snapshot/backup storage * `t [source]
- If avoiding in-memory sorts is critical, place sort fields before range fields (ESR) - If your range predicate in the query is very selective, then put it before sort fields (ERS) [source]
The `length` and `sort` arguments are added to the relevant field names: [source]
Defines an index in the database. [source]
Query by reading documents from an index on this table. [source]
This query's cost is relative to the number of documents that match the index range expression. [source]
Results will be returned in index order. [source]
* The query that yields documents in the index. [source]
For example, `by_channel_user` includes `channel`, `user`, and `_creationTime`. So queries on `messages` that use `.withIndex("by_channel_user")` will be sorted first by channel, then by user within each channel, and finally by the creation time. [source]
If the query optimizer considered more than one plan, [`executionStats`](https://www.mongodb.com/docs/manual/reference/explain-results/#mongodb-data-explain.executionStats) information also includes the *partial* execution information captured during the [plan selection phase](https://www.mongodb.com/docs/manual/core/query-plans/#std-label-query-plans-query-optimization) for both the winning and rejected candidate plans. [source]
Specifying `@@id([firstName, lastName], name: "fullName")` will change the Prisma Client API to this instead: [source]
An indexed field can define the operator class, which defines the operators handled by the index. [source]
Prisma ORM generally supports operator classes provided by PostgreSQL in versions 10 and later. If the operator class requires the field type to be of a type Prisma ORM does not yet support, using the `raw` function with a string input allows you to use these operator classes without validation. [source]
| Operator class | Allowed field type (native types) | Default | Other | | -------------- | --------------------------------- | ------- | ----------------------------- | | `ArrayOps` | Any array | ✅ | Also available in CockroachDB | | `JsonbOps` | `Json` (`@db.JsonB`) | ✅ | Also available in CockroachDB | | `JsonbPathOps` | `Json` (`@db.JsonB`) | | | | `raw("other")` | | | | [source]
Read more about built-in operator classes in the [official PostgreSQL documentation](https://www.postgresql.org/docs/14/gin-builtin-opclasses.html). [source]
Queries comparing IP addresses, such as `value > '10.0.0.2'`, will use the index. [source]
| Operator class | Allowed field type (allowed native types) | | -------------- | ----------------------------------------- | | `InetOps` | `String` (`@db.Inet`) | | `raw("other")` | | [source]
Read more about built-in operator classes in the [official PostgreSQL documentation](https://www.postgresql.org/docs/14/gist-builtin-opclasses.html). [source]
As with GiST, SP-GiST is important as a building block for user-defined types, allowing implementation of custom search operators directly with the database. [source]
As an example, the following model adds a `SpGist` index to the `value` field with `TextOps` as the operators using the index: [source]
Queries such as `value LIKE 'something%'` will be sped up by the index. [source]
| Operator class | Allowed field type (native types) | Default | Supported PostgreSQL versions | | -------------- | ------------------------------------ | ------- | ----------------------------- | | `InetOps` | `String` (`@db.Inet`) | ✅ | 10+ | | `TextOps` | `String` (`@db.Text`, `@db.VarChar`) | ✅ | | | `raw("other")` | | | | [source]
Read more about built-in operator classes from [official PostgreSQL documentation](https://www.postgresql.org/docs/14/spgist-builtin-opclasses.html). [source]
Prisma ORM generally supports operator classes provided by PostgreSQL in versions 10 and later, and some supported operators are only available from PostgreSQL versions 14 and later. If the operator class requires the field type to be of a type Prisma ORM does not yet support, using the `raw` function with a string input allows you to use these operator classes without validation. [source]
| Operator class | Allowed field type (native types) | Default | Supported PostgreSQL versions | | --------------------------- | ------------------------------------ | ------- | ----------------------------- | | `BitMinMaxOps` | `String` (`@db.Bit`) | ✅ | | | `VarBitMinMaxOps` | `String` (`@db.VarBit`) | ✅ | | | `BpcharBloomOps` | `String` (`@db.Char`) | | 14+ | | `BpcharMinMaxOps` | `St [source]
Read more about built-in operator classes in the [official PostgreSQL documentation](https://www.postgresql.org/docs/14/brin-builtin-opclasses.html). [source]
| Value type | Example | Notes | | ---------------- | ---------------------------------------- | ------------------------------------------------------ | | `Boolean` | `{ active: true }`, `{ deleted: false }` | For `Boolean` fields | | `String` | `{ status: "active" }` | For `String`, `DateTime`, and `Enum` fields | | `Number` | `{ priority: 1 }`, `{ score: 1.5 }` | For `Int`, `BigInt`, `Float`, and `Decimal` fields [source]
The `where` argument can be combined with other index arguments such as `name` and `map`: [source]
> [!NOTE] > The introspected `raw()` string reflects the database's normalized form of the SQL expression, which may differ from what you originally wrote. For example, PostgreSQL adds parentheses and explicit type casts (e.g., `'active'::text`), SQL Server wraps column names in brackets and adds parentheses (e.g., `([status]='active')`), while SQLite generally preserves the original expression as-is. [source]
This index allows fast searches for keys and values within `jsonb` fields for tenants: [source]
The most common form indexes one or more columns by name. [source]
Turso supports a `USING` clause to specify an alternative index method. [source]
Once an FTS index exists, use the `search()` function to query it: [source]
Remove an index from the database. The underlying table and its data are not affected. [source]
This must have the same length as the `dimensions` of the index. This vector search will return the IDs of the documents most similar to this vector. [source]
The names of indexes in a table for a given [GenericTableInfo](/api/modules/server.md#generictableinfo). [source]
For a ranged sharded collection, only the following indexes can be [unique:](https://www.mongodb.com#std-label-index-type-unique) [source]
If you frequently query certain document fields, you can specify those fields in a `wildcardProjection` to support those queries without adding unnecessary bloat to the index. [source]
1 db.runCommand ( 2 { 3 listIndexes: "contacts" 4 } 5 ) [source]
The wildcard pattern `"$**"` includes all of the fields in the document. However, the `wildcardProjection` field excludes the specified fields from the index. [source]
For complete documentation on `wildcardProjection`, see [Options for `wildcard` indexes.](https://www.mongodb.com#std-label-createIndex-method-wildcard-option) [source]
The following operation creates an index with a [commit quorum](https://www.mongodb.com#std-label-createIndex-method-commitQuorum) of `"majority"`, or a simple majority of data-bearing voting members: [source]
The following example creates two indexes on the `products` collection: an ascending index on the `manufacturer` field and an ascending index on the `category` field. Both indexes use a [collation](https://www.mongodb.com/docs/manual/reference/method/db.collection.createIndex/#std-label-create-index-collation) that specifies the locale `fr` and comparison strength `2`: [source]
For queries or sort operations on the indexed keys that uses the same collation rules, MongoDB can use the index. For details, see [Collation and Index Use.](https://www.mongodb.com/docs/manual/reference/method/db.collection.createIndex/#std-label-createIndex-collation-index-use) [source]
const specification = { "accounts.bank": 1, "accounts.number": 1 }; const options = { name: "Unique Account", unique: true }; db.users.createIndex(specification, options); // Unique Account [source]
Using iterative index scans, Postgres will scan the approximate index for nearest neighbors, apply additional filters and, if the number of neighbors after filtering is insufficient, it will continue scanning until sufficient results are found. [source]
Even with this optimization you are still just looping over the table to find the first post that matches and may hit your function limits. Using indexes is still the way to go. You can read a [detailed discussion of how to handle tags with indexes](https://stack.convex.dev/complex-filters-in-convex#optimize-with-indexes). [source]
{ queryPlanner: { ... winningPlan: { queryPlan: { stage: 'COLLSCAN', ... } } }, executionStats: { executionSuccess: true, nReturned: 3, executionTimeMillis: 0, totalKeysExamined: 0, totalDocsExamined: 10, executionStages: { stage: 'COLLSCAN', ... }, ... }, ... } [source]
mmary, MongoDB Compass displays the query stages `FETCH` and`IXSCAN` .`IXSCAN` indicates that the[`mongod`](https://www.mongodb.com/docs/manual/reference/program/mongod/#mongodb-binary-bin.mongod) used an index to satisfy the query before executing the`FETCH` stage and retrieving the documents. [source]
This creates an index optimized for vector similarity searches on the `embedding` column. [source]
<Step title="Query the indexed table"> ```sql theme={null} SELECT title, year FROM vector_top_k('movies_idx', vector32('[0.064, 0.777, 0.661, 0.687]'), 3) JOIN movies ON movies.rowid = id WHERE year >= 2020; ``` [source]
This query uses the `vector_top_k` [table-valued function](https://www.sqlite.org/vtab.html#table_valued_functions) to efficiently find the top 3 most similar vectors to `[0.064, 0.777, 0.661, 0.687]` using the index. </Step> </Steps> [source]
| Operation | FTS behavior | | --------- | ----------------------------------------------------------------------- | | `INSERT` | New rows are indexed immediately (batched commits every 1000 documents) | | `UPDATE` | Implemented as DELETE + INSERT internally | | `DELETE` | Marks documents as deleted via tombstones, cleaned up on OPTIMIZE | [source]
| Name | Type | | ------------- | ------------------------------------------------------------------------- | | `Document` | extends [`GenericDocument`](/api/modules/server.md#genericdocument) | | `IndexFields` | extends [`GenericIndexFields`](/api/modules/server.md#genericindexfields) | | `FieldNum` | extends `number` = `0` | [source]
* `LowerBoundIndexRangeBuilder`<`Document`, `IndexFields`\[`FieldNum`]> [source]
↳ **`IndexRangeBuilder`** [source]
▸ **eq**(`fieldName`, `value`): `NextIndexRangeBuilder`<`Document`, `IndexFields`, `FieldNum`> [source]
`NextIndexRangeBuilder`<`Document`, `IndexFields`, `FieldNum`> [source]
▸ **gt**(`fieldName`, `value`): `UpperBoundIndexRangeBuilder`<`Document`, `IndexFields`\[`FieldNum`]> [source]
`UpperBoundIndexRangeBuilder`<`Document`, `IndexFields`\[`FieldNum`]> [source]
LowerBoundIndexRangeBuilder.gt [source]
▸ **gte**(`fieldName`, `value`): `UpperBoundIndexRangeBuilder`<`Document`, `IndexFields`\[`FieldNum`]> [source]
LowerBoundIndexRangeBuilder.gte [source]
LowerBoundIndexRangeBuilder.lt [source]
LowerBoundIndexRangeBuilder.lte [source]
| Name | Type | | ----------- | ---------------------------------------- | | `IndexName` | extends `string` \| `number` \| `symbol` | [source]
Look through your indexes, either in your `schema.ts` file or in the dashboard, and look for any indexes where one is a prefix of another. [source]
The [`explain()`](https://www.mongodb.com/docs/manual/reference/method/cursor.explain/#mongodb-method-cursor.explain) method returns the following results: [source]
* Block level: `@@id`, `@@unique`, `@@index`, `@@map` * Field level : `@id`, `@unique`, `@default`, `@updatedAt`, `@map`, `@relation` [source]
| Index | Supported | Prisma schema | Prisma Client | Prisma Migrate | | -------------- | :--------------------------------------: | :------------------------------------------------------------------------------------------------------------: | :-----------: | :------------: | | `UNIQUE` | ✔️ | [`@unique` and `@@unique`](https://www.prisma.io/docs/orm/v7/prisma-schema/data-model/models#defining-a-unique-f [source]
The *name* of the `fields` argument on the `@@index` attribute can be omitted: [source]
* Replicate the change you made in production in the schema - for example, add an `@@index` to a particular model. * Generate a new migration and take note of the full migration name, including a timestamp, which is written to the CLI:(`20210316150542_retroactively_add_index`): [source]
* The [`length` argument](#configuring-the-length-of-indexes-with-length-mysql) allows you to specify a maximum length for the subpart of the value to be indexed on `String` and `Bytes` types * Available on the `@id`, `@@id`, `@unique`, `@@unique` and `@@index` attributes * MySQL only [source]
* The [`sort` argument](#configuring-the-index-sort-order-with-sort) allows you to specify the order that the entries of the constraint or index are stored in the database * Available on the `@unique`, `@@unique` and `@@index` attributes in all databases, and on the `@id` and `@@id` attributes in SQL Server [source]
* The [`clustered` argument](#configuring-if-indexes-are-clustered-or-non-clustered-with-clustered-sql-server) allows you to configure whether a constraint or index is clustered or non-clustered * Available on the `@id`, `@@id`, `@unique`, `@@unique` and `@@index` attributes * SQL Server only [source]
* The [`map` argument](#configuring-the-name-of-indexes-with-map) allows you to specify a custom name for the index or constraint in the underlying database * Available on the `@id`, `@@id`, `@unique`, `@@unique` and `@@index` attributes * Supported in all databases [source]
The `length` argument is available on the `@id`, `@@id`, `@unique`, `@@unique` and `@@index` attributes. [source]
A similar syntax can be used for the `@@unique` and `@@index` attributes. [source]
| Attribute | Value | | ---------- | ------- | | `@id` | `true` | | `@@id` | `true` | | `@unique` | `false` | | `@@unique` | `false` | | `@@index` | `false` | [source]
The `map` argument is available on the `@id`, `@@id`, `@unique`, `@@unique` and `@@index` attributes. [source]
For MongoDB composite types, use dot notation: `@@index([address.city.name])` [source]
Extracts a sub-array by index range. [source]
An expression representing an index range created by [IndexRangeBuilder](/api/interfaces/server.IndexRangeBuilder.md). [source]
**Important:** Prefer using `.withIndex()` over `.filter()` whenever possible. Filters scan all documents matched so far and discard non-matches, while indexes efficiently skip non-matching documents. Define an index in your schema for fields you filter on frequently. [source]
1. Define the index in your `convex/schema.ts` file. 2. Query via the `withIndex()` syntax. [source]
Let’s assume you’re building a chat app and want to get all messages in a particular channel. You can define a new index called `by_channel` on the `messages` table by using the `.index()` method in your schema. [source]
Queries that use `withIndex` are ordered by the columns specified in the index. [source]
If you use an index without a range expression, you should always use one of the following in conjunction with `withIndex`: [source]
This query demonstrates the difference between filtering using [`withIndex`](/api/interfaces/server.QueryInitializer.md#withindex) and [`filter`](/api/interfaces/server.Query.md#filter). `withIndex` only allows you to restrict your query based on the index. You can only do operations that the index can do efficiently like finding all documents with a given author. [source]
One approach is to build a separate `by_title` index on `title`. This could let us swap the work we do in `.filter` and `.withIndex` to instead be: [source]
Here the index range expression tells Convex to only consider documents where the author is Isaac Asimov and the title is *Foundation*. This is only a single document so this query will be quite fast! [source]
This query uses the index to find books where `author === "Isaac Asimov" && "F" <= title < "G"`. Once again, the performance of this query is based on how many documents are in the index range. In this case, that's just the Asimov books that begin with "F" which is quite small. [source]
Also note that this index also supports our original query for "books by Jane Austen." It's okay to only use the `author` field in an index range expression and not restrict by title at all. [source]
3. You can use `undefined` in filters and index queries, and it will match documents that do not have the field. i.e. `.withIndex("by_a", q=>q.eq("a", undefined))` matches document `{}` and `{b: 1}`, but not `{a: 1}` or `{a: null, b: 1}`.  * In Convex's ordering scheme, `undefined < null < all other values`, so you can match documents that *have* a field via `q.gte("a", null as any)` or `q.gt("a", undefined)`. [source]
| | | Notes | | -------------------------- | ------ | --------------------------------------------------------- | | Data read | 16 MiB | Data not returned due to a `filter` counts as scanned | | Data written | 16 MiB | | | Documents scanned | 32,000 | Documents not returned due to a `filter` count as scanned | | Index ranges read | 4,096 | The number of calls to `db.get` and `db.query`. | [source]
The `map` argument can also be used on unique constraints: [source]
The following example demonstrates adding a `@@fulltext` index to the `title` and `content` fields of a `Post` model: [source]
On MongoDB, you can use the `@@fulltext` index attribute (via the `fullTextIndex` preview feature) with the `sort` argument to add fields to your full-text index in ascending or descending order. The following example adds a `@@fulltext` index to the `title` and `content` fields of the `Post` model, and sorts the `title` field in descending order: [source]
export const user = cockroachTable('user', { id: int4().unique(), }); [source]
export const table = cockroachTable('table', { id: int4().unique('custom_name'), }); [source]
export const composite = cockroachTable('composite_example', { id: int4(), name: string(), }, (t) => [ unique().on(t.id, t.name), unique('custom_name').on(t.id, t.name) ]); [source]
export const user = mssqlTable('user', { id: int().unique(), }); [source]
export const table = mssqlTable('table', { id: int().unique('custom_name_1'), }); [source]
export const composite = mssqlTable('composite_example', { id: int(), name: varchar({ length: 256 }), }, (t) => [ unique().on(t.id, t.name), unique('custom_name_2').on(t.id, t.name) ]); ``` [source]
```sql CREATE TABLE [user] ( [id] int, CONSTRAINT [user_id_key] UNIQUE([id]) ); [source]
export const user = mysqlTable('user', { id: int().unique(), }); [source]
export const user = pgTable('user', { id: integer().unique(), }); [source]
export const table = pgTable('table', { id: integer().unique('custom_name'), }); [source]
export const composite = pgTable('composite_example', { id: integer(), name: text(), }, (t) => [ unique().on(t.id, t.name), unique('custom_name').on(t.id, t.name) ]); [source]
// In Postgres 15.0+ NULLS NOT DISTINCT is available // This example demonstrates both available usages export const userNulls = pgTable("user_nulls_example", { id: integer(), id2: integer().unique("custom_name", { nulls: "not distinct" }), }, (t) => [ unique().on(t.id).nullsNotDistinct() ]); ``` [source]
export const user = singlestoreTable('user', { id: int('id').unique(), }); [source]
export const table = singlestoreTable('table', { id: int('id').unique('custom_name'), }); [source]
export const composite = singlestoreTable('composite_example', { id: int('id'), name: varchar('name', { length: 256 }), }, (t) => [ unique().on(t.id, t.name), unique('custom_name').on(t.id, t.name) ]); ``` [source]
export const user = sqliteTable('user', { id: int('id').unique(), }); [source]
export const table = sqliteTable('table', { id: int('id').unique('custom_name'), }); [source]
export const composite = sqliteTable('composite_example', { id: int('id'), name: text('name'), }, (t) => [ unique().on(t.id, t.name), unique('custom_name').on(t.id, t.name) ]); ``` [source]
You should see the two apparel rows first - a good sanity check that the index works. [source]
`pgvector` supports two types of indexes: [source]
While querying, you can specify the size of the candidate list that will be searched (`hnsw_ef`): [source]
Vectors with up to 2,000 dimensions can be indexed. [source]
LibSQL introduces a custom index type that helps speed up nearest neighbors queries against a fixed distance function (cosine similarity by default). [source]
▸ \*\* indexes\*\*(): { `indexDescriptor`: `string` ; `fields`: `string`\[] }\[] [source]
Returns indexes defined on this table. Intended for the advanced use cases of dynamically deciding which index to use for a query. If you think you need this, please chime in on ths issue in the Convex JS GitHub repo. <https://github.com/get-convex/convex-js/issues/49> [source]
{ `indexDescriptor`: `string` ; `fields`: `string`\[] }\[] [source]
<https://docs.convex.dev/database/reading-data/indexes> [source]
Search queries must always search for some text within the index's `searchField`. This query can optionally add equality filters for any `filterFields` specified in the index. [source]
This query is saying "look through all of the books, left-to-right, and collect the ones where the `author` field is Jane Austen." To do this the librarian will need to look through the entire shelf and check the author of every book. [source]
1. A name.  * Must be unique per table. [source]
Geospatial data is worked with using GeoJSON and legacy formats to create indexes and perform queries. [source]
MongoDB\Collection::dropIndexes() drops all indexes in a collection except the _id index. [source]
Information about all indexes in a collection can be retrieved using the MongoDB\Collection::listIndexes() method. [source]
Compound indexes allow indexing on multiple fields simultaneously. [source]
Geospatial indexes support queries involving location-based data. [source]
Multikey indexes are used for arrays of values within documents. [source]
Clustered collections utilize clustered indexes to define the physical order of documents within a collection. [source]
Wildcard indexes support queries on arbitrary or unknown fields in collections with flexible schemas using the `$**` specifier. [source]
Optimize MongoDB queries by creating indexes, using projections, limiting results, and utilizing covered queries. [source]
The `create` command creates collections or views in MongoDB with options for capped collections, time series, and clustered indexes. [source]
The `createIndexes` command builds one or more indexes on a collection with options for write concern, commit quorum, and index types. [source]
The `drop` command removes an entire collection from a database, which also deletes associated indexes and handles in-progress index builds. [source]
The $toHashedIndexKey operator computes hash values in an aggregation pipeline using the same hash function as MongoDB's hashed index but without collation. [source]
The $toHashedIndexKey operator uses the same hash function as MongoDB's hashed index but operates without collation. [source]
In Prisma v6, the `UNIQUE INDEX` is changing into a `PRIMARY KEY`: [source]
For anything the operation factories don't cover (enabling an extension, `CREATE INDEX CONCURRENTLY`, a vendor-specific statement), use `rawSql`, and keep the same three-phase safety if you can: [source]
Introspection read an unrecognized or malformed database shape — an unknown referential action rule, or a malformed index reloption entry. Raised by the Postgres and SQLite control adapters. Meta: `rule`, `entry`, `indexName`. [source]
An authored wire-name prefix (an index name, an RLS policy prefix, or a check's `name:` prefix) exceeds the 54-byte maximum — Postgres identifiers cap at 63 bytes and the wire name appends a 9-byte `_<8hex>` content-hash suffix. Raised at contract lowering. Meta: `prefix`, `maxBytes`. [source]
The output reports the planned operations: creating the `users` and `posts` collections and a unique index on `users.email`. [source]
| Name | Required | Type | Description | | ----------- | -------- | ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ [source]
Prisma Migrate is able to create constraints and indexes with the `length` argument if specified in your data model. This means that you can create indexes and constraints on values of Prisma schema type `Byte` and `String`. If you don't specify the argument the index is treated as covering the full value as before. [source]
The `sort` argument can also be used on compound indexes: [source]
As an example, the following model adds a `Gin` index to the `value` field, with `JsonbPathOps` as the class of operators allowed to use the index: [source]
As an example, the following model adds a `Gist` index to the `value` field with `InetOps` as the operators that will be using the index: [source]
The BRIN index type is useful if you have lots of data that does not change after it is inserted, such as date and time values. If your data is a good fit for the index, it can store large datasets in a minimal space. [source]
As an example, the following model adds a `Brin` index to the `value` field with `Int4BloomOps` as the operators that will be using the index: [source]
A table can have at most one clustered index. [source]
> [!NOTE] > Partial indexes are supported on **PostgreSQL**, **SQLite**, **SQL Server**, and **CockroachDB**. They are **not** supported on MySQL. [source]
1. Automatically add `"partialIndexes"` to the `previewFeatures` list in your generator block 2. Represent the partial index predicate using the `raw()` syntax with the database's normalized form of the SQL expression [source]
See [custom index names](https://www.prisma.io/docs/orm/v7/prisma-schema/data-model/database-mapping#constraint-and-index-names) for naming customization. [source]
* Table name: `_CategoryToPost` (underscore + model names alphabetically + `To`) * Columns: `A` (FK to first model alphabetically) and `B` (FK to second) * Unique index on both columns, non-unique index on `B` [source]
Upsert with composite indexes, or composite primary keys for `onConflictDoUpdate`: [source]
Drizzle has simple and flexible API, which lets you easily create such an index using SQL-like syntax: <CodeTabs items={["schema.ts", "migration.sql"]}> <CodeTab> ```ts copy {12,13} import { SQL, sql } from 'drizzle-orm'; import { AnyPgColumn, pgTable, serial, text, uniqueIndex } from 'drizzle-orm/pg-core'; [source]
Drizzle has simple and flexible API, which lets you easily create such an index using SQL-like syntax: <CodeTabs items={["schema.ts", "migration.sql"]}> <CodeTab> ```ts copy {12,13} import { SQL, sql } from 'drizzle-orm'; import { AnyMySqlColumn, mysqlTable, serial, uniqueIndex, varchar } from 'drizzle-orm/mysql-core'; [source]
// custom lower function export function lower(email: AnySQLiteColumn): SQL { return sql`lower(${email})`; } ``` </CodeTab> ```sql CREATE TABLE `users` ( `id` integer PRIMARY KEY NOT NULL, `name` text NOT NULL, `email` text NOT NULL ); --> statement-breakpoint CREATE UNIQUE INDEX `emailUniqueIndex` ON `users` (lower(`email`)); ``` </CodeTabs> [source]
Drizzle ORM provides API for both `index` and `unique index` declaration: [source]
<Section> ```typescript copy {9-10} import { int, varchar, index, uniqueIndex, mssqlTable } from "drizzle-orm/mssql-core"; [source]
export const user = mssqlTable("user", { id: int().primaryKey().identity(), name: varchar({ length: 256 }), email: varchar({ length: 256 }), }, (table) => [ index("name_idx").on(table.name), uniqueIndex("email_idx").on(table.email), ]); ``` ```sql {5-6} CREATE TABLE `user` ( ... ); [source]
```typescript // Index declaration reference index("name") .on(table.name) .algorithm("default") // "default" | "copy" | "inplace" .using("btree") // "btree" | "hash" .lock("default") // "none" | "default" | "exclusive" | "shared" ``` [source]
<Callout> For optimal performance in one-to-one relationships, you should create an index on the foreign key column in the table that is being referenced (the "target" table in the relation). </Callout> [source]
<Callout> For one-to-many relationships, create an index on the foreign key column in the table that represents the "many" side of the relationship (the table with the foreign key referencing the "one" side). </Callout> [source]
<Callout> For many-to-many relationships, it is generally recommended to create the following indexes on the junction table: 1. **Index on each foreign key column individually:** This optimizes queries that filter or join based on a single side of the relationship (e.g., finding all groups for a user OR all users in a group). 2. **Composite index on both foreign key columns together:** This is crucial for efficiently resolving the many-to-many relationship itself. It speeds up queries that need to find the connections between both entities. </Callout> [source]
// `.on()` index('name') .on(table.column1.asc(), table.column2.nullsFirst(), ...) .concurrently() .where(sql``) .with({ fillfactor: '70' }) [source]
// `.onOnly()` index('name') .onOnly(table.column1.asc(), table.column2.nullsFirst(), ...) .concurrently() .where(sql``) .with({ fillfactor: '70' }) [source]
export const user = singlestoreTable("user", { id: int("id").primaryKey().autoincrement(), name: text("name"), email: text("email"), }, (table) => [ index("name_idx").on(table.name), uniqueIndex("email_idx").on(table.email), ]); ``` ```sql {5-6} CREATE TABLE `user` ( ... ); [source]
<Section> ```typescript {8-9} import { integer, text, index, uniqueIndex, sqliteTable } from "drizzle-orm/sqlite-core"; [source]
Note that to create an index on `halfvec`, you need to specify the distance function as `halfvec_l2_ops` or `halfvec_cosine_ops`. [source]
A B-tree index can be created on a `CITEXT` column just like a `TEXT` column: [source]
* hstore is generally more efficient than JSON for simple key-value pairs * GIN indexes can significantly improve query performance on hstore columns * The storage size of hstore is typically smaller than equivalent JSON storage [source]
* GiST indexes significantly improve range query performance * IP address operations are very efficient as they use native integer comparisons * Range operations are optimized for both IPv4 and IPv6 * Indexes work well with both IP versions in the same column [source]
* **Fast Full-Text Search**: Efficient searching using bigram matching * **Similarity Calculation**: Built-in functions to measure string similarity * **Partial Matching**: Find strings containing specific patterns * **Language Agnostic**: Works well with any language, including non-Latin scripts * **GIN Index Support**: Fast search performance using GIN indexes [source]
* `pg_bigm.similarity_threshold`: Default similarity threshold (0.0 to 1.0) * `pg_bigm.enable_recheck`: Whether to recheck similarity in search results * `pg_bigm.gin_key_limit`: Maximum number of bigrams for GIN index [source]
1. **Indexing**: * Always create spatial indexes (GiST) on geometry columns * Use appropriate coordinate systems for your use case [source]
1. Create GiST indexes on seg columns: [source]
2. Common operators that can use the GiST index: [source]
B-Tree indexes play a crucial role in enhancing database performance by allowing faster retrieval of specific rows. Imagine them as the index pages in a book, providing quick references to relevant data. [source]
* B-tree indexes are organized as balanced tree structures. * Each level of the tree acts like a doubly-linked list of pages. * The index starts with a metapage at the beginning of the first segment file. * All other pages are either leaf pages (the lowest level) or internal pages. [source]
await db.run(sql` CREATE INDEX IF NOT EXISTS vector_index ON vector_table(vector) USING vector_cosine(3) `); ``` </Step> [source]
Show index names, optionally filtered by table. [source]
| Feature | Description | | ------------------------------------------------------------------------------- | -------------------------------------------------------- | | [CREATE TYPE](/sql-reference/statements/create-type) | User-defined types for STRICT tables | | [CREATE MATERIALIZED VIEW](/sql-reference/statements/create-materialized-view) | Live materialized views with incremental maintenance | | [BEGIN CONCURRENT](/sql-re [source]
FTS indexes are created with the `USING fts` clause on `CREATE INDEX`. Each indexed column participates in the full-text search. [source]
* [CREATE INDEX](/sql-reference/statements/create-index) for the full `CREATE INDEX ... USING fts` syntax * [Vector Functions](/sql-reference/functions/vector) for similarity search with embeddings [source]
* [CREATE INDEX](/sql-reference/statements/create-index) for index types including FTS * [Data Types](/sql-reference/data-types) for how BLOBs are handled in Turso [source]
<Info> The new table name must not collide with an existing table, view, or index name in the same database. </Info> [source]
| Form | Description | | --------------------- | -------------------------------------------------------- | | `ANALYZE` | Analyze all tables and indexes in all attached databases | | `ANALYZE schema-name` | Analyze all tables and indexes in the named database | | `ANALYZE table-name` | Analyze all indexes on the named table | | `ANALYZE index-name` | Analyze the named index | [source]
* [ALTER TABLE](/sql-reference/statements/alter-table) for modifying existing tables * [DROP TABLE](/sql-reference/statements/drop-table) for removing tables * [Data Types](/sql-reference/data-types) for type affinity and STRICT table types * [CREATE INDEX](/sql-reference/statements/create-index) for indexing table columns * [CREATE TYPE](/sql-reference/statements/create-type) for custom types in STRICT tables * [INSERT](/sql-reference/statements/insert) for adding rows to a table [source]
The `<` operator is special: it controls how values of this type are sorted in ORDER BY, MIN, MAX, and CREATE INDEX. [source]
Function form of dot notation — `union_extract(col, 'variant')` is equivalent to `col.variant`. Primarily useful in expression indexes: [source]
For partial unique indexes (indexes with a `WHERE` clause), the conflict target must also include a `WHERE` clause that matches the index's condition. [source]
CDC also tracks DDL operations (CREATE TABLE, DROP TABLE, CREATE INDEX, etc.) as changes to the `sqlite_schema` table: [source]
It's an object mapping each index name to the fields in the index. [source]
This will be an object mapping index names to the fields in the index. [source]
Ƭ **IndexNames**<`TableInfo`>: keyof [`Indexes`](/api/modules/server.md#indexes)<`TableInfo`> [source]
Ƭ **NamedIndex**<`TableInfo`, `IndexName`>: [`Indexes`](/api/modules/server.md#indexes)<`TableInfo`>\[`IndexName`] [source]
**Best practice:** Always include all index fields in the index name. For example, an index on `["field1", "field2"]` should be named `"by_field1_field2"`. [source]
Similarly, even after an index is defined, Convex will have to do a bit of extra work to keep this index up to date as the data changes. Every time a document is inserted, updated, or deleted in an indexed table, Convex will also update its index entry. This is analogous to a librarian creating new index cards for new books as they add them to the library. [source]
Focusing on the second step, the `vectorSearch` API takes in the table name, the index name, and finally a [`VectorSearchQuery`](/api/interfaces/server.VectorSearchQuery.md) object describing the search. This object has the following fields: [source]
In the event of a rolling index build cancellation, Atlas generates an [activity feed event](https://www.mongodb.com/docs/atlas/tutorial/activity-feed/#std-label-view-activity-feed) and sends a notification email to the project owner with the following information: [source]
- Completion date of the index build - Name of the cluster on which the index build completed - Namespace on which the index build completed - Project containing the cluster and namespace - Organization containing the project - Link to the [activity feed event](https://www.mongodb.com/docs/atlas/tutorial/activity-feed/#std-label-view-activity-feed) [source]
For example, the following image shows a compound index where documents are first sorted by `userid` in ascending order (alphabetically). Then, the `scores` for each `userid` are sorted in descending order: [source]
This section describes technical details and limitations for compound indexes. [source]
Indexes store references to fields in either ascending (`1`) or descending (`-1`) sort order. For compound indexes, sort order can determine whether the index supports a sort operation. For more information, see [Compound Index Sort Order.](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-compound/sort-order/#std-label-index-compound-sort-order) [source]
MongoDB's indexing strategy eliminates any need to arrange exact match fields in a particular order. However, if the query does not specify an equality condition on an index prefix that precedes or overlaps with the sort specification, the operation will not efficiently use the index. For more information, see [Sort and Non-prefix Subset of an Index.](https://www.mongodb.com/docs/manual/tutorial/sort-results-with-indexes/#std-label-sort-index-nonprefix-subset) [source]
For example, to create a unique index on the `email` field of the `users` collection, use the following operation in `mongosh`: [source]
For example, to create a unique index on `name`, `email`, and `password` fields of the `users` collection, use the following operation in `mongosh`: [source]
The unique index permits the insertion of the following documents into the collection since the index enforces uniqueness for the *combination* of `email` and `name` values: [source]
- the index on the shard key - a [compound index](https://www.mongodb.com/docs/manual/reference/glossary/#std-term-compound-index) where the shard key is a[prefix](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-compound/#std-label-compound-index-prefix) - The default `_id` index; however, the`_id` index only enforces the uniqueness constraint**per shard** if the`_id` field is not the shard key. [source]
Unique indexes ensure that a value appears at most once for a given field. [source]
This example adds a unique index on the `user_id` field of a `members` collection to ensure that there are no duplicate values in the `user_id` field. [source]
MongoDB supports creating indexes on a field, or set of fields, to improve performance for queries. MongoDB supports [flexible schemas](https://www.mongodb.com/docs/manual/data-modeling/#std-label-manual-data-modeling-intro), meaning document field names may differ within a collection. Use wildcard indexes to support queries against arbitrary or unknown fields. [source]
- If your application queries a collection where field names vary between documents, create a wildcard index to support queries on all possible document field names. - If your application repeatedly queries an embedded document field where the subfields are not consistent, create a wildcard index to support queries on all of the subfields. - If your application queries documents that share common characteristics. A compound wildcard index can efficiently cover many queries for documents that have common fields. To learn more, see [Compound Wildcard Indexes.](https://www.mongodb.com/docs/manual [source]
| Index | Default Name | |---|---| | `{ score : 1 }` | `score_1` | | `{ content : "text", "description.tags": "text" }` | `content_text_description.tags_text` | | `{ category : 1, locale : "2dsphere"}` | `category_1_locale_2dsphere` | | `{ "fieldA" : 1, "fieldB" : "hashed", "fieldC" : -1 }` | `fieldA_1_fieldB_hashed_fieldC_-1` | [source]
- To learn how to create an index, see [Create an Index.](https://www.mongodb.com/docs/manual/core/indexes/create-index/#std-label-manual-create-an-index) - For more information about index properties, see [Index Properties.](https://www.mongodb.com/docs/manual/core/indexes/index-properties/#std-label-index-properties) [source]
If you drop an index that's actively used in production, you may experience performance degradation. Before you drop an index, consider [hiding the index](https://www.mongodb.com/docs/manual/core/index-hidden/#std-label-index-type-hidden) to evaluate the potential impact of the drop. [source]
After you drop an index, the system returns information about the status of the operation. [source]
The dropped index no longer appears in the `getIndexes()` output. [source]
Multikey indexes collect and sort data stored in arrays. [source]
This image shows a multikey index on the `addr.zip` field: [source]
Wildcard indexes apply to collections with flexible schemas, where document field names may differ. Use wildcard indexes to support queries against arbitrary or unknown field names. [source]
Geospatial indexes improve performance for queries on geospatial coordinate data. To learn more, see [Geospatial Indexes.](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-geospatial/#std-label-geospatial-index) [source]
Hashed indexes support [hashed sharding](https://www.mongodb.com/docs/manual/core/hashed-sharding/#std-label-sharding-hashed-sharding). Hashed indexes index the hash of a field's value. [source]
Clustered indexes specify the order in which [clustered collections](https://www.mongodb.com/docs/manual/core/clustered-collections/#std-label-clustered-collections) store data. Collections created with a clustered index are called clustered collections. [source]
2d indexes support certain query operators that calculate distances using spherical geometry. Spherical query operators use radians for distance. To use spherical query operators with a 2d index, you must convert distances to radians. [source]
2d indexes support the following spherical query operators: [source]
The default location bounds for 2d indexes allow latitudes less than -90 and greater than 90, which are invalid values. The behavior of geospatial queries with these invalid points is not defined. [source]
Defining a smaller location range for a 2d index reduces the amount of data stored in the index, and can improve query performance. [source]
The index covers a smaller location range and has increased performance than a default 2d index. [source]
This document explains the internals of [2d indexes](https://www.mongodb.com/docs/manual/core/indexes/index-types/geospatial/2d/#std-label-2d-index). This material is not necessary for normal operations or application development, but may be useful for troubleshooting and for further understanding. [source]
While 2d indexes do not support more than one location field in a document, you can use a [multi-key index](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-multikey/#std-label-index-type-multi-key) to index multiple coordinate pairs in a single document. For example, in the following document, the `locs` field holds an array of coordinate pairs: [source]
- To perform proximity queries on a spherical surface, see [Query for Locations Near a Point on a Sphere.](https://www.mongodb.com/docs/manual/core/indexes/index-types/geospatial/2dsphere/query/proximity-to-geojson/#std-label-2dsphere-query-geojson-proximity) [source]
2dsphere indexes are available in the following versions: [source]
| 2dsphere Index Version | Description | |---|---| | Version 4 | MongoDB 8.3 introduces version 4 of 2dsphere indexes. Version 4 is the default version for 2dsphere indexes created in MongoDB 8.3 and later. | | Version 3 | MongoDB 3.2 introduces version 3 of 2dsphere indexes. Version 3 is the default version for 2dsphere indexes created in MongoDB 3.2 and later. | | Version 2 | MongoDB 2.6 introduces version 2 of 2dsphere indexes. Version 2 is the default version for 2dsphere indexes created in MongoDB 2.6 to 3.0. | | Version 1 | MongoDB 2.4 introduces version 1 of 2dsphere indexes. MongoDB 2. [source]
The following command creates a version 2 2dsphere index on the `address` field: [source]
You regularly run a query that returns students with at least one `test_score` greater than `90`. You can create an index on the `test_scores` field to improve performance for this query. [source]
The following operation creates an ascending multikey index on the `test_scores` field of the `students` collection: [source]
For example, consider a compound index `{ temperature: 1, humidity: 1 }` with the following bounds: [source]
MongoDB compounds the bounds for the `item` key with either the bounds for `"ratings.score"` or the bounds for `"ratings.by"`, depending upon the query predicates and the index key values. MongoDB does not guarantee which bounds it compounds with the `item` field. [source]
- The index keys must share the same field path up to but excluding the field names. - The query must specify predicates on the fields using `$elemMatch` on that path. [source]
For a field in an embedded document, the [dotted field name](https://www.mongodb.com/docs/manual/core/document/#std-label-document-dot-notation), such as `"a.b.c.d"`, is the field path for `d`. To compound the bounds for index keys from the same array, the `$elemMatch` must be on the path up to *but excluding* the field name itself (meaning `"a.b.c"`). [source]
The following example shows how MongoDB combines bounds for index keys from the same array. This example uses the `survey2` collection used in the [previous example.](https://www.mongodb.com#std-label-index-bounds-example-non-array-multiple-array) [source]
In order for a [dot notation](https://www.mongodb.com/docs/manual/reference/glossary/#std-term-dot-notation) query to use an index, you must create an index on the specific embedded field you are querying, not the entire embedded object. For an example, see [Create an Index on an Embedded Field.](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-single/create-single-field-index/#std-label-index-embedded-fields) [source]
- An ascending or descending index key on the `department` field - A `text` index key on the`description` field [source]
After you create the compound index, `$text` queries only scan documents that match a specified equality condition on the `department` field. [source]
The following operation creates a wildcard index on all document fields in the `artwork` collection (excluding `_id`): [source]
If there are document fields that you rarely query, you can create a wildcard index that omits those fields. [source]
The following operation creates a wildcard index on all document fields in the `products` collection, but omits the `attributes.memory` field from the index: [source]
Wildcard indexes do not replace workload-based index planning. [source]
This example creates a compound wildcard index on the `salesData` collection: [source]
The wildcard index term, `"$**"`, specifies every field in the collection. The `wildcardProjection` limits the index to the specified fields, `"customFields.addr"` and `"customFields.name"`. [source]
The following example creates a partial compound wildcard index on the `tenantId` field and on all the sub-fields in the `customFields` field, only on documents with a `tenantRegion` of `1`. [source]
The wildcard index continues traversing any additional embedded objects or arrays until it reaches a primitive value. It then indexes the primitive value, along with the full path to that field. [source]
A wildcard index that includes the `account` field descends into the `account` object to traverse and index its contents: [source]
A wildcard index which includes the `ship` field descends into the object to traverse and index its contents: [source]
Wildcard indexes do not record the array position of any given element in an array during indexing. However, MongoDB may still use the wildcard index to fulfill a query that includes a field path with one or more explicit array indices. [source]
Sharded collections require an index that supports the [shard key](https://www.mongodb.com/docs/manual/reference/glossary/#std-term-shard-key). The index can be an index on the shard key or a [compound index](https://www.mongodb.com/docs/manual/reference/glossary/#std-term-compound-index) where the shard key is a [prefix](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-compound/#std-label-compound-index-prefix) of the index. [source]
- If the collection is empty, [`sh.shardCollection()`](https://www.mongodb.com/docs/manual/reference/method/sh.shardCollection/#mongodb-method-sh.shardCollection) creates the unique index on the shard key if such an index does not already exist. - If the collection is not empty, you must create the index first before using [`sh.shardCollection()`.](https://www.mongodb.com/docs/manual/reference/method/sh.shardCollection/#mongodb-method-sh.shardCollection) [source]
After you know which fields your application frequently queries, you can create indexes to support queries on those fields. For more information, see [Examples.](https://www.mongodb.com#std-label-schema-design-indexes-examples) [source]
If your application only queries on a single key in a given collection, then you need to create a single-key index for that collection. For example, you can create an index on `title` in the `movies` collection: [source]
{ "_id": { <ResumeToken> }, "operationType": "dropIndexes", "clusterTime": <Timestamp> "collectionUUID": <uuid>, "wallTime": <isodate>, "ns": { "db": "test", "coll": "authors" }, "operationDescription": { "indexes": [ { "v": 2, "key": { "name": 1 }, "name": "name_1" } ] } } [source]
- `dropIndexes`- *Changed in version 6.0.* :The [`dropIndexes`](https://www.mongodb.com#mongodb-dbcommand-dbcmd.dropIndexes) command drops one or more indexes (except the index on the`_id` field and the last remaining shard key index, if one exists) from the specified collection.## TipIn [`mongosh`](https://www.mongodb.com/docs/mongodb-shell/#std-program-mongosh) , this command can also be run through the[`db.collection.dropIndex()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.dropIndex/#mongodb-method-db.collection.dropIndex) and[`db.collection.dropIndexes()`](https://w [source]
If the method is passed an array of index names that includes a non-existent index, the method errors without dropping any of the specified indexes. [source]
If an index specified to [`dropIndexes`](https://www.mongodb.com#mongodb-dbcommand-dbcmd.dropIndexes) is still building, [`dropIndexes`](https://www.mongodb.com#mongodb-dbcommand-dbcmd.dropIndexes) attempts to stop the in-progress build. Stopping an index build has the same effect as dropping the built index. [source]
If after the evaluation, the user decides to drop the index, you can drop the hidden index; i.e. you do not need to unhide it first to drop it. [source]
For more information on hidden indexes, see [Hidden Indexes.](https://www.mongodb.com/docs/manual/core/index-hidden/) [source]
[Index Builds on Populated Collections](https://www.mongodb.com/docs/manual/core/index-creation/) for more information on the behavior of indexing operations in MongoDB. [source]
- Using the ordering of the `{ item: 1, type: 1 }` index,[`min()`](https://www.mongodb.com#mongodb-method-cursor.min) limits the query to the documents that are at or above the index key bound of`item` equal to`apple` and`type` equal to`jonagold` , as in the following:db.products.find().min( { item: 'apple', type: 'jonagold' } ).hint( { item: 1, type: 1 } ) The query returns the following documents: { "_id" : 3, "item" : "apple", "type" : "jonagold", "price" : Decimal128("1.29") } { "_id" : 4, "item" : "apple", "type" : "jonathan", "price" : Decimal128("1.29") } { "_id" : 5, "item" : "apple", [source]
dering of the index `{ price: 1 }` ,[`min()`](https://www.mongodb.com#mongodb-method-cursor.min) limits the query to the documents that are at or above the index key bound of`price` equal to`1.39` and[`max()`](https://www.mongodb.com/docs/manual/reference/method/cursor.max/#mongodb-method-cursor.max) limits the query to the documents that are below the index key bound of`price` equal to`1.99` :db.products.find().min( { price: Decimal128("1.39") } ).max( { price: Decimal128("1.99") } ).hint( { price: 1 } ) The query returns the following documents: { "_id" : 10, "item" : "orange", "type" : "nav [source]
The following option is available for [2dsphere](https://www.mongodb.com/docs/manual/core/indexes/index-types/geospatial/2dsphere/#std-label-2dsphere-index) indexes only: [source]
| Parameter | Type | Description | |---|---|---| | `2dsphereIndexVersion` | integer | Optional. The `2dsphere` index version number. Users can use this option to override the default version number. For the available versions, see [2dsphere Indexes.](https://www.mongodb.com/docs/manual/core/indexes/index-types/geospatial/2dsphere/#std-label-2dsphere-v2) | [source]
[Wildcard indexes](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-wildcard/#std-label-wildcard-index-core) can use the `wildcardProjection` option. [source]
If you call [`db.collection.createIndex()`](https://www.mongodb.com#mongodb-method-db.collection.createIndex) for an index that already exists, MongoDB does not recreate the index. [source]
With the exception of the [collation option](https://www.mongodb.com#std-label-method-createIndex-collation-option), if you create an index with one set of index options and then try to recreate the same index but with different index options, MongoDB will not change the options nor recreate the index. [source]
The [hidden](https://www.mongodb.com/docs/manual/reference/command/createIndexes/#std-label-createIndexes-hidden-option) option can be changed without dropping and recreating the index. See [Hidden Option.](https://www.mongodb.com#std-label-method-createIndex-hidden-option) [source]
- To change the `hidden` option for an index to`true` , use the[`db.collection.hideIndex()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.hideIndex/#mongodb-method-db.collection.hideIndex) method:db.movies.hideIndex( { title: 1 } ) - To change the `hidden` option for an index to`false` , use the[`db.collection.unhideIndex()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.unhideIndex/#mongodb-method-db.collection.unhideIndex) method:db.movies.unhideIndex( { title: 1 } ) [source]
The following table compares the index build behavior starting in MongoDB 7.1 with earlier versions. [source]
Each [`mongod`](https://www.mongodb.com/docs/manual/reference/program/mongod/#mongodb-binary-bin.mongod) in the replica set or sharded cluster *must* have [featureCompatibilityVersion](https://www.mongodb.com/docs/manual/reference/command/setFeatureCompatibilityVersion/#std-label-set-fcv) set to at least `4.4` to start index builds simultaneously across replica set members. [source]
Index builds on a replica set or sharded cluster build simultaneously across all data-bearing replica set members. For sharded clusters, the index build occurs only on shards containing data for the collection being indexed. The primary requires a minimum number of data-bearing [`voting`](https://www.mongodb.com/docs/manual/reference/replica-configuration/#mongodb-rsconf-rsconf.members-n-.votes) members (i.e commit quorum), including itself, that must complete the build before marking the index as ready for use. See [Index Builds in Replicated Environments](https://www.mongodb.com/docs/manual/ [source]
`commitQuorum` specifies how many data-bearing voting members, or which voting members, including the primary, must be prepared to commit the index build before the primary will execute the commit. The default commit quorum is `votingMembers`, which means all data-bearing members. [source]
For example, you can use the following code to create a compound index on the `movies` collection of the `sample_mflix` database specifying the numeric fields `year` and `metacritic` and the string field `title`. The index also specifies the collation locale `"fr"` for string comparisons: [source]
The following operation creates a wildcard index on the `awards` field: [source]
With this wildcard index, MongoDB indexes all scalar values of `awards`. If the field is a nested document or array, the wildcard index recurses into the document or array and indexes all scalar fields in the document or array. [source]
The wildcard index can support arbitrary single-field queries on `awards` or one of its nested fields: [source]
The following operation creates a wildcard index on all scalar fields (excluding the `_id` field): [source]
With this wildcard index, MongoDB indexes all scalar fields for each document in the collection. If a given field is a nested document or array, the wildcard index recurses into the document or array and indexes all scalar fields in the document or array. [source]
The following operation creates a wildcard index and uses the `wildcardProjection` option to include only scalar values of the `tomatoes.viewer` and `tomatoes.critic` fields in the index. [source]
The wildcard index supports queries on any scalar field included in the `wildcardProjection`: [source]
This example uses a wildcard index and a `wildcardProjection` document to index the scalar fields for each document in the collection. [source]
The wildcard index excludes the `tomatoes.viewer` and `tomatoes.critic` fields: [source]
- `db.collection.createIndexes( [ keyPatterns ], options, commitQuorum )`- Creates one or more indexes on a collection. [source]
The following example creates two indexes on the `restaurants` collection: an ascending index on the `borough` field and a [2dsphere](https://www.mongodb.com/docs/manual/core/indexes/index-types/geospatial/2dsphere/#std-label-2dsphere-index) index on the `location` field. [source]
The following operation creates a wildcard index on the `product_attributes` field: [source]
With this wildcard index, MongoDB indexes all scalar values of `product_attributes`. If the field is a nested document or array, the wildcard index recurses into the document/array and indexes all scalar fields in the document/array. [source]
The wildcard index can support arbitrary single-field queries on `product_attributes` or one of its nested fields: [source]
Wildcard indexes omit the `_id` field by default. To include the `_id` field in the wildcard index, you must explicitly include it in the `wildcardProjection` document. See [parameter documentation](https://www.mongodb.com#std-label-createIndexes-method-wildcard-option) for more information. [source]
The following operation creates a wildcard index and uses the `wildcardProjection` option to include only scalar values of the `product_attributes.colors` and `product_attributes.material` fields in the index. [source]
This example uses a wildcard index and a `wildcardProjection` document to index the scalar fields for each document in the collection. The wildcard index excludes the `product_attributes.colors` and `product_attributes.material` fields: [source]
The single field index on the field `cat` has the user-specified name of `catIdx` and the index specification document of `{ "cat" : -1 }`. [source]
Or you can use the index specification document `{ "cat" : -1 }`: [source]
The `dropIndex` command returns the number of indexes in the collection prior to the command being run, and indicates whether the command was successful: [source]
[`db.collection.getIndexes()`](https://www.mongodb.com#mongodb-method-db.collection.getIndexes) returns an array of documents that hold index information for the collection. For example: [source]
For information on the keys and index options, see `db.collection.createIndex()`. [source]
- The amount of time a query took to complete - Whether the query used an index - The number of documents and index keys scanned to fulfill a query [source]
1. Click the Indexes tab for the `test.inventory` collection. 2. Click Create Index. 3. Select `quantity` from the Select a field name dropdown. 4. Select `1 (asc)` from the type dropdown. 5. Click Create. [source]
For example, add the following two compound indexes. The first index orders by `quantity` field first, and then the `type` field. The second index orders by `type` first, and then the `quantity` field. [source]
Only use a [rolling index build](https://www.mongodb.com/docs/manual/core/rolling-index-builds/#std-label-rolling-index-build) if your deployment matches one of the following cases: [source]
If your deployment does not meet this criteria, use the [default index build.](https://www.mongodb.com/docs/manual/core/index-creation/#std-label-index-operations) [source]
With Atlas, you can temporarily [scale](https://www.mongodb.com/docs/atlas/scale-cluster/) your cluster to meet the requirements for a traditional index build. However, Atlas charges to scale your cluster. See [Cluster Configuration Costs](https://www.mongodb.com/docs/atlas/billing/cluster-configuration-costs/) for more information. [source]
Rolling index builds lower the resiliency of your cluster and increase build duration. [source]
The following procedure to build indexes in a rolling fashion applies to replica set deployments, and not sharded clusters. For the procedure for sharded clusters, see [Create Rolling Index Builds on Sharded Clusters](https://www.mongodb.com/docs/manual/tutorial/build-indexes-on-sharded-clusters/) instead. [source]
For example, connect [`mongosh`](https://www.mongodb.com/docs/mongodb-shell/#mongodb-binary-bin.mongosh) to the instance, and use the [`createIndex()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.createIndex/#mongodb-method-db.collection.createIndex) to create an ascending index on the `username` field of the `records` collection: [source]
s/manual/reference/method/db.collection.dropIndex/#mongodb-method-db.collection.dropIndex) from a[`mongos`](https://www.mongodb.com/docs/manual/reference/program/mongos/#mongodb-binary-bin.mongos) to drop the index from the collection. [source]
For example, if you want to create an index on the `records` collection in the `test` database: [source]
A [compound index](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-compound/#std-label-index-type-compound) references multiple fields and can dramatically improve query response times. [source]
Index searches make efficient use of exact matches to reduce the number of index keys examined. Equality fields must come first. [source]
- To ensure the `bank` and`number` fields do not repeat, make the index[unique.](https://www.mongodb.com/docs/manual/core/index-unique/#std-label-index-type-unique) - To allow indexing of multiple fields, make the index [compound.](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-compound/#std-label-index-type-compound) - To allow indexing of documents inside an array, make the index of the type [multikey.](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-multikey/#std-label-index-type-multikey) [source]
const specification = { "accounts.bank": 1, "accounts.number": 1 }; const optionsV2 = { name: "Unique Account V2", partialFilterExpression: { "accounts.bank": { $exists: true }, "accounts.number": { $exists: true } }, unique: true }; db.users.drop( {} ); // Delete previous documents and indexes definitions db.users.createIndex(specification, optionsV2); // Unique Account V2 [source]
Defines a compound [unique constraint](https://www.prisma.io/docs/orm/v7/prisma-schema/data-model/models#defining-a-unique-field) for the specified fields. [source]
The `find` command executes queries to retrieve documents with options such as sort order, limits, projections, index hints, collation, and read concern. [source]
db.collection.reIndex() recreates all indexes on a collection and is resource-intensive, available only on standalone instances. [source]
> **Note**: Before the `partialIndexes` Preview feature (and before version 4.0.0 / 3.5.0 with the `extendedIndexes` Preview feature), the signature was: > > ```prisma no-lines > @@unique(_ fields: FieldReference[], name: String?, map: String?) > ``` [source]
The `length` argument is specific to MySQL and allows you to define indexes and constraints on columns of `String` and `Byte` types. For these types, MySQL requires you to specify a maximum length for the subpart of the value to be indexed in cases where the full value would exceed MySQL's limits for index sizes. See [the MySQL documentation](https://dev.mysql.com/doc/refman/8.0/en/innodb-limits.html) for more details. [source]
* Reduced storage requirements (half the memory) * Faster query performance * Reduced index size (both in disk and memory) * Can index vectors with up to 4096 dimensions (which covers the most popular embedding models) [source]
* Not suitable for very short strings (less than 3 characters) * May produce false positives * Index size can be large for big text columns * Not ideal for exact matching (use standard indexes instead) [source]
Collect statistics about indexes to help the query optimizer [source]
▸ **withIndex**<`IndexName`>(`indexName`, `indexRange?`): [`Query`](/api/interfaces/server.Query.md)<`TableInfo`> [source]
- Use the [`$indexStats`](https://www.mongodb.com/docs/manual/reference/operator/aggregation/indexStats/#mongodb-pipeline-pipe.-indexStats) aggregation stage. - For MongoDB Atlas deployments, view [Indexes](https://www.mongodb.com/docs/atlas/atlas-ui/indexes/#std-label-atlas-ui-view-indexes) in the Atlas UI. [source]
s. Index hints don't affect [query shape.](https://www.mongodb.com/docs/manual/core/query-shapes/#std-label-query-shapes)For more information about hints and query settings, see [Query Settings Syntax.](https://www.mongodb.com/docs/manual/reference/command/setQuerySettings/#std-label-setQuerySettings-syntax) [source]
Unless the [`find()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.find/#mongodb-method-db.collection.find) query is an equality condition on the `_id` field `{ _id: <value> }`, you must explicitly specify the index with the [`hint()`](https://www.mongodb.com/docs/manual/reference/method/cursor.hint/#mongodb-method-cursor.hint) method to run `min()`. [source]
MongoDB Compass provides an [Explain Plan](https://www.mongodb.com/docs/compass/current/query-plan/) tab, which displays statistics about the performance of a query. These statistics can be useful in measuring if and how a query uses an index. [source]
The more selective the equality matches, the more efficient the indexed query. [source]
n stage returns information about common[query shapes](https://www.mongodb.com/docs/manual/core/query-shapes/#std-label-query-shapes) .`$queryStats` provides a holistic view of the kinds of queries being run on your deployment. | | View index statistics | Atlas clusters and self-hosted deployments | The [`$indexStats`](https://www.mongodb.com/docs/manual/reference/operator/aggregation/indexStats/#mongodb-pipeline-pipe.-indexStats) aggregation stage returns information about your collection's indexes and how often individual indexes are used. Use`$indexStats` to identify unused indexes that can [source]
Search and AI Recommendations skills provide guidance on configuring search indexes and integrating AI capabilities into applications. [source]
Search and AI Recommendations provides guidance for implementing MongoDB Atlas Search and AI-powered recommendations, including configuring search indexes. [source]
MongoDB Vector Search — > Use MongoDB Vector Search to create vector indexes and perform vector search, including semantic search and hybrid search, on your vector embeddings in MongoDB. [source]
MongoDB Vector Search enables the creation of vector indexes to perform semantic and hybrid search on vector embeddings within MongoDB. [source]
The dateFacet field type includes date values for faceting in a search index. [source]
The numberFacet field type includes numeric values of int32, int64, and double data types in the search index for faceted search. [source]
MongoDB Search Indexes are supported for search functionality within the C Driver. [source]
MongoDB Search and MongoDB Vector Search indexes can be created and managed using the .NET/C# driver. [source]
Text queries can be performed by creating text indexes and sorting results by relevance. [source]
MongoDB\Collection::createSearchIndex() creates a Search or Vector Search index, available for Atlas deployments with a minimum M10 cluster tier. [source]
MongoDB\Collection::listSearchIndexes() retrieves index information for all search indexes in a collection with customizable options. [source]
Updating a MongoDB Search index via MongoDB\Collection::updateSearchIndex() requires an Atlas cluster tier of at least M10. [source]
Indexes should be used with Mongoid to improve query performance, including compound, geospatial, and Search indexes. [source]
Atlas Search Indexes are supported for search capabilities within the driver. [source]
Text indexes enhance search performance on string fields and support $text queries with case and diacritic insensitivity. [source]
MongoDB 7.0 release notes cover improvements in sharding, storage, internal operations, Atlas Search index management, and aggregation enhancements. [source]
> Use MongoDB Vector Search to create vector indexes and perform vector search, including semantic search and hybrid search, on your vector embeddings in MongoDB. [source]
After that, `pgvector.Vector(1536)` is a column type in your contract, vector operators appear in the query builder, and `migration plan` knows how to create vector indexes. See [Using extensions](https://www.prisma.io/docs/orm/extensions/using-extensions). [source]
If you use the [full-text index](https://www.prisma.io/docs/orm/v7/prisma-schema/data-model/indexes#full-text-indexes-mysql-and-mongodb) feature in your app, you can now remove `fullTextIndex` from the `previewFeatures` in your Prisma schema: [source]
* models, fields, and relations, plus how they map to tables and columns * storage details: primary keys, unique constraints, indexes, and foreign keys * named types, enums, and value objects * types and capabilities contributed by extension packs, such as pgvector's `Vector` * content hashes that identify this exact version of the schema [source]
- [`External tables`](https://www.prisma.io/docs/orm/v7/prisma-schema/data-model/externally-managed-tables): How to declare and use externally managed tables in Prisma ORM - [`Indexes`](https://www.prisma.io/docs/orm/v7/prisma-schema/data-model/indexes): How to configure index functionality and add full text indexes - [`Models`](https://www.prisma.io/docs/orm/v7/prisma-schema/data-model/models): Learn about the concepts for building your data model with Prisma: Models, scalar types, enums, attributes, functions, IDs, default values and more - [`Multi-schema`](https://www.prisma.io/docs/orm/v7/ [source]
How to configure index functionality and add full text indexes [source]
* In MySQL/MariaDB, you can specify sort order (`ASC`/`DESC`) directly in unique constraints and indexes * In PostgreSQL, sort order can only be specified on indexes, not on unique constraints * In SQL Server, sort order is supported on all constraints and indexes including `@id` and `@@id` [source]
Before you can generate embeddings or create text search indexes for documents, you need to prepare them. The preparation steps depend on the document type and the retrieval method you choose. For example, if you use PDFs or HTML documents, you will need to extract the text from them. If you used scanned documents, you will need to use OCR to extract the text. [source]
DiskANN index support for PostgreSQL with pgvectorscale [source]
The `pgvectorscale` extension adds diskANN index support for pgvector. This extension is useful in cases where `pgvector`'s `hnsw` index does not fit into available memory and as a result the ANN search does not perform as expected. [source]
* StreamingDiskANN index - disk-backed HNSW variant. * Statistical Binary Quantization (SBQ) * Label-based filtering combined with DiskANN index. [source]
* Create a label column in your table. It has to be an array of `smallint`s. Other types will revert to using the post-filtering. * Create a diskann index that uses both the embedding and the label column. * Use the `&&` (array intersection) operator in search queries. * Optional, but recommended: Use a separate table and joins to translate smallint labels to meaningful descriptions. [source]
* DiskANN index supports `cosine`, `l2` and `inner_product` distance metrics, not the entire pgvector's set of distance metrics. * Label-based filtering is only supported for `smallint` arrays and the `&&` operator. Other types will revert to using the post-filtering. * DiskANN is best suited for datasets where `hnsw` index would be too large to fit into memory. For smaller datasets, `hnsw` is still a good choice. [source]
* Exact and approximate nearest neighbor search (with optional HNSW and IVFFlat indexes) * Single-precision, half-precision, binary, and sparse vectors * L2 distance, inner product, cosine distance, L1 distance, Hamming distance, and Jaccard distance * Any language with a Postgres client Plus ACID compliance, point-in-time recovery, JOINs, and all of the other great features of Postgres [source]
Without vector indexes (also called **flat indexes** by other vector stores), queries sequentially scan through all vectors for the given query, and compute the distance to the query vector. This is computationally expensive, but guarantees to find the nearest neighbors (also called **exact nearest neighbors** or **KNN**). [source]
<Card title="Pgvectorscale" href="./pgvectorscale" icon="vector-square"> DiskANN index support for pgvector </Card> [source]
DiskANN index support for pgvector [source]
<Note> Vector index works only for column with one of the vector types described above </Note> [source]
LibSQL vector index optionally can accept settings which must be specified as variadic parameters of the `libsql_vector_idx` function as strings in the format `key=value`: [source]
| Setting key | Value type | Description | | -------------------- | ------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- [source]
<Note> Vector index for column of type `T1` with `max_neighbors=M` and `compress_neighbors=T2` will approximately use $\texttt{N} (Storage(\texttt {T1}) + \texttt{M} \cdot Storage(\texttt{T2}))$ storage bytes for `N` rows. </Note> [source]
Queries lacking index support perform a full table scan, incurring a row scan for each table row. [source]
SQL updates read (and write) each row they modify. Absent an index for row filtering, a full table scan is performed, adding a read for each table row, plus a write for each updated row. [source]
<Note> By default, similarity searches use a linear scan over the table. An experimental sparse vector index method is available behind the `--experimental-index-method` flag; without it, consider limiting search to a subset of rows with a WHERE clause for large datasets. </Note> [source]
[`TableDefinition`](/api/classes/server.TableDefinition.md)<`DocumentType`, `Indexes`, `SearchIndexes`, `VectorIndexes`> [source]
A [TableDefinition](/api/classes/server.TableDefinition.md) with this vector index included. [source]
▸ `Protected` **self**(): [`TableDefinition`](/api/classes/server.TableDefinition.md)<`DocumentType`, `Indexes`, `SearchIndexes`, `VectorIndexes`> [source]
Query by running a full text search against a search index. [source]
| Name | Type | Description | | ----------- | -------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------- | | `fieldName` | `FieldName` | The name of the field to compare. This must be listed in the [source]
The configuration for a full text search index. [source]
| Name | Type | | -------------------------- | -------------------------------------------------------- [source]
The configuration for a vector index. [source]
A type describing the configuration of a search index. [source]
A type describing all of the search indexes in a table. [source]
A type describing the configuration of a vector index. [source]
A type describing all of the vector indexes in a table. [source]
The search indexes in a table for a given [GenericTableInfo](/api/modules/server.md#generictableinfo). [source]
The names of search indexes in a table for a given [GenericTableInfo](/api/modules/server.md#generictableinfo). [source]
Extract the config of a search index from a [GenericTableInfo](/api/modules/server.md#generictableinfo) by name. [source]
The vector indexes in a table for a given [GenericTableInfo](/api/modules/server.md#generictableinfo). [source]
The names of vector indexes in a table for a given [GenericTableInfo](/api/modules/server.md#generictableinfo). [source]
Extract the config of a vector index from a [GenericTableInfo](/api/modules/server.md#generictableinfo) by name. [source]
Ƭ **DataModelFromSchemaDefinition**<`SchemaDef`>: `MaybeMakeLooseDataModel`<{ \[TableName in keyof SchemaDef\["tables"] & string]: SchemaDef\["tables"]\[TableName] extends TableDefinition\<infer DocumentType, infer Indexes, infer SearchIndexes, infer VectorIndexes> ? Object : never }, `SchemaDef`\[`"strictTableNameTypes"`]> [source]
* To search a vector index, use the `vectorSearch` field. Read on about [Vector Search](/search/vector-search.md). [source]
| | Value | | ------------------------ | ----- | | Search indexes per table | 4 | | Filters per search index | 16 | | Terms per search query | 16 | | Filters per search query | 8 | | Maximum term length | 32 B | | Maximum result set | 1024 | [source]
| | Value | | ------------------------ | ------------------------ | | Vector indexes per table | 4 | | Filters per vector index | 16 | | Terms per search query | 16 | | Vectors to search by | 1 | | Dimension fields | 1 (value between 2-4096) | | Filters per search query | 64 | | Maximum term length | 32 B | | Maximum result set | 256 (defaults to 10) | [source]
1. Define a search index. 2. Run a search query. [source]
Search indexes are built and queried using Convex's multi-segment search algorithm on top of [Tantivy](https://github.com/quickwit-oss/tantivy), a powerful, open-source, full-text search library written in Rust. [source]
3. \[Optional] A list of `filterField`s  * These are additional fields that are indexed for fast equality filtering within your search index. [source]
This is just a normal [database read](/database/reading-data/.md) that begins by querying the search index! [source]
Search expressions are issued against a search index, filtering and ranking documents by their relevance to the search expression's query. Internally, Convex will break up the query into separate words (called *terms*) and approximately rank documents matching these terms. [source]
1. First, querying the search index using the search filter expression in `withSearchIndex`. 2. Then, filtering the results one-by-one using any additional `filter` expressions. [source]
Additionally, search queries can scan up to 1024 results from the search index. [source]
1. Define a vector index. 2. Run a vector search from within an [action](/functions/actions.md). [source]
* Exactly 1 vector index field.  * The field must be of type `v.array(v.float64())` (or a union in which one of the possible types is `v.array(v.float64())`) * Exactly 1 dimension field with a value between 2 and 4096. * Up to 16 filter fields. [source]
- Create namespaces and attributes - Add indexes and unique constraints - Model relationships - Lock down your schema for production [source]
Text indexes support `$text` queries on fields containing string content. [source]
[MongoDB Search](https://www.mongodb.com/docs/atlas/atlas-search/) offers advanced full-text search capabilities, including [configurable dynamic indexing](https://www.mongodb.com/docs/search/index/define-field-mappings/#std-label-fts-configure-dynamic-mappings). We recommend using [MongoDB Search indexes](https://www.mongodb.com/docs/search/index/manage-indexes/#std-label-fts-manage-indexes) instead of text indexes. [source]
The wildcard text index supports `$text` queries on all fields in the collection. Consider the following queries: [source]
This page describes the behavior of [version 3](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-text/text-index-versions/#std-label-text-index-versions) text indexes. [source]
Text indexes are case insensitive. The text index does not distinguish between capitalized and lower-case characters, such as `e` and `E`. [source]
Text indexes support case foldings as specified in [Unicode 8.0 Character Database Case Folding](http://www.unicode.org/Public/8.0.0/ucd/CaseFolding.txt): [source]
[Previous text index versions](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-text/text-index-versions/#std-label-text-index-versions) are only case insensitive for non-diacritic Latin characters `[A-z]`. Previous text index versions treat all other characters as distinct. [source]
[Previous versions](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-text/text-index-versions/#std-label-text-index-versions) of the text index treat characters with diacritics as distinct. [source]
For tokenization, text indexes use the delimiters categorized under `Dash`, `Hyphen`, `Pattern_Syntax`, `Quotation_Mark`, `Terminal_Punctuation`, and `White_Space` in the [Unicode 8.0 Character Database Prop List](http://www.unicode.org/Public/8.0.0/ucd/PropList.txt). [source]
MongoDB supports `$text` queries for various languages. Text indexes use simple language-specific suffix stemming. Text indexes also drop language-specific stop words such as `the`, `an`, `a`, and `and` in English. For a list of the supported languages, see [$text Query Languages on Self-Managed Deployments.](https://www.mongodb.com/docs/manual/reference/text-search-languages/#std-label-text-search-languages) [source]
| Text Index Version | Description | |---|---| | Version 3 | MongoDB 3.2 introduces version 3 of text indexes. Version 3 is the default version for text indexes created in MongoDB 3.2 and later. | | Version 2 | MongoDB 2.6 introduces version 2 of text indexes. Version 2 is the default version for text indexes created in MongoDB 2.6 to 3.0. | | Version 1 | MongoDB 2.4 introduces version 1 of text indexes. MongoDB 2.4 only supports version 1. | [source]
The following command creates a version 2 text index on the `content` field: [source]
For self-managed (non-Atlas) deployments, MongoDB provides a `text` index type that supports searching for string content in a collection. To learn more about self-managed text indexes, see [Text Indexes on Self-Managed Deployments.](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-text/#std-label-index-feature-text) [source]
b.com/docs/manual/core/indexes/index-types/index-text/specify-text-index-language/#std-label-specify-language-field-text-index-example) for an example. | | `textIndexVersion` | integer | Optional. The `text` index version number. Users can use this option to override the default version number. For available versions, see [Text Index Versions on Self-Managed Deployments.](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-text/text-index-versions/#std-label-text-index-versions) | [source]
Queries that perform filter or sort operations that show a `COLLSCAN` stage would benefit from an index. [source]
@@unique([firstname, lastname, id]) } ``` [source]
Composite IDs and compound unique constraints can be defined in your Prisma schema using the [`@@id`](https://www.prisma.io/docs/orm/v7/reference/prisma-schema-reference) and [`@@unique`](https://www.prisma.io/docs/orm/v7/reference/prisma-schema-reference) attributes. [source]
* `@id` or `@@id` for primary key * `@unique` or `@@unique` for unique constraint [source]
Recommended indexes are accompanied by sample queries, grouped by [query shape](https://www.mongodb.com/docs/manual/reference/glossary/#std-term-query-shape), that were run against a collection that would benefit from the suggested index. The Performance Advisor doesn't negatively affect the performance of your Atlas clusters. [source]
The Performance Advisor ranks the indexes according to their Impact, which is based on the total wasted bytes read by the associated operations. To learn more about how the Performance Advisor ranks indexes, see [Review Index Ranking.](https://www.mongodb.com/docs/atlas/performance-advisor/index-ranking/#std-label-pa-index-ranking) [source]
For each suggested index, the Performance Advisor shows the most commonly executed query shapes that the index would improve. For each query shape, the Performance Advisor displays the following metrics: [source]
By default, the Performance Advisor suggests indexes for all clusters in the deployment. To only show suggested indexes from a specific collection, use the Collection dropdown at the top of the Performance Advisor. [source]
The Performance Advisor includes a user feedback button for Index Suggestions on dedicated clusters. [source]
Indexes are available for query optimization within the Django MongoDB Backend. [source]
The `EXPLAIN QUERY PLAN` prefix provides a high-level description of the strategy the query optimizer chose for executing a statement. This output is more useful than raw EXPLAIN for understanding query performance. [source]
* [Experimental Features](/sql-reference/experimental-features) for enabling in-place `VACUUM` * [PRAGMAs](/sql-reference/pragmas) for `auto_vacuum`, `journal_mode`, `query_only`, and `wal_checkpoint` * [ATTACH DATABASE](/sql-reference/statements/attach-database) for attaching a schema that can be targeted by `VACUUM INTO` * [ANALYZE](/sql-reference/statements/analyze) for refreshing query planner statistics after a vacuum [source]
▸ **withSearchIndex**<`IndexName`>(`indexName`, `searchFilter`): [`OrderedQuery`](/api/interfaces/server.OrderedQuery.md)<`TableInfo`> [source]
Ƭ **NamedVectorIndex**<`TableInfo`, `IndexName`>: [`VectorIndexes`](/api/modules/server.md#vectorindexes)<`TableInfo`>\[`IndexName`] [source]
- `cursor.explain(verbosity)`- ## Important**mongosh Method**This page documents a [`mongosh`](https://www.mongodb.com/docs/mongodb-shell/#mongodb-binary-bin.mongosh) method. This is*not* the documentation for a language-specific driver, such as Node.js.For MongoDB API drivers, refer to the language-specific [MongoDB driver documentation.](https://www.mongodb.com/docs/drivers/)Provides information on the query plan for the [`db.collection.find()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.find/#mongodb-method-db.collection.find) method.The `explain()` method has the fo [source]
MongoDB runs the [query optimizer](https://www.mongodb.com/docs/manual/core/query-plans/#std-label-read-operations-query-optimization) to choose the winning plan for the operation under evaluation. [`cursor.explain()`](https://www.mongodb.com#mongodb-method-cursor.explain) returns the [`queryPlanner`](https://www.mongodb.com/docs/manual/reference/explain-results/#mongodb-data-explain.queryPlanner) information for the evaluated method. [source]
MongoDB runs the [query optimizer](https://www.mongodb.com/docs/manual/core/query-plans/#std-label-read-operations-query-optimization) to choose the winning plan, executes the winning plan to completion, and returns statistics describing the execution of the winning plan. [source]
MongoDB runs the [query optimizer](https://www.mongodb.com/docs/manual/core/query-plans/) to choose the winning plan and executes the winning plan to completion. In `"allPlansExecution"` mode, MongoDB returns statistics describing the execution of the winning plan as well as statistics for the other candidate plans captured during [plan selection.](https://www.mongodb.com/docs/manual/core/query-plans/#std-label-query-plans-query-optimization) [source]
If you run `cursor.explain()` against a database that does not exist on a sharded cluster, the execution stage reaches the end-of-stream and the operation does not create the database. For more information on end-of-stream execution stats, see `explain.executionStats.executionStages.isEOF`. [source]
The verbosity mode (i.e. `queryPlanner`, `executionStats`, `allPlansExecution`) determines whether the results include [`executionStats`](https://www.mongodb.com/docs/manual/reference/explain-results/#std-label-executionStats) and whether [`executionStats`](https://www.mongodb.com/docs/manual/reference/explain-results/#std-label-executionStats) includes data captured during [plan selection.](https://www.mongodb.com/docs/manual/core/query-plans/#std-label-query-plans-query-optimization) [source]
The following example runs [`cursor.explain()`](https://www.mongodb.com#mongodb-method-cursor.explain) in ["executionStats"](https://www.mongodb.com/docs/manual/reference/method/db.collection.explain/#std-label-explain-method-executionStats) verbosity mode to return the query planning and execution information for the specified [`db.collection.find()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.find/#mongodb-method-db.collection.find) operation: [source]
.mongodb.com/docs/manual/reference/explain-results/#mongodb-data-explain.executionStats.totalDocsExamined) displays`10` to indicate that MongoDB had to scan ten documents (i.e. all documents in the collection) to find the three matching documents. [source]
If the range predicate in your query is very selective, place it before the sort fields to reduce the number of sorted documents and allow an in-memory sort. [source]
Queries can execute in several stages. At each stage, MongoDB collects documents from the previous stage to perform the next set of operations. [`explain.executionStats.executionStages`](https://www.mongodb.com/docs/manual/reference/explain-results/#mongodb-data-explain.executionStats.executionStages) provides information on each execution stage, where each level of the [`inputStage`](https://www.mongodb.com/docs/manual/reference/explain-results/#mongodb-data-explain.executionStats.executionStages.inputStage) field shows how MongoDB selected documents for the stage. [source]
Queries that use filters to specify the results may have issues. To identify an inefficient filter, compare the value on the [`executionStats.totalDocsExamined`](https://www.mongodb.com/docs/manual/reference/explain-results/#mongodb-data-explain.executionStats.totalDocsExamined) field to that of the [`executionStats.nReturned`](https://www.mongodb.com/docs/manual/reference/explain-results/#mongodb-data-explain.executionStats.nReturned) field. [source]
The `extendedIndexes` feature is now generally available, with support for: [source]
The `length` argument can also be used on compound primary keys, using the `@@id` attribute, as in the example below: [source]
The `UNIQUE` constraint ensures that all values in a column are different. [source]
Both the `UNIQUE` and `PRIMARY KEY` constraints provide a guarantee for uniqueness for a column or set of columns. [source]
A `PRIMARY KEY` constraint automatically has a `UNIQUE` constraint. [source]
<Callout type="info" emoji="ℹ️"> You can have many `UNIQUE` constraints per table, but only one `PRIMARY KEY` constraint per table. </Callout> [source]
Just like `PRIMARY KEY`, composite primary key uniquely identifies each record in a table using multiple fields. [source]
export const table = mssqlTable("table", { int: int().default(42), time: time().default(sql`cast('14:06:10' AS TIME)`), }); ``` ```sql CREATE TABLE [table] ( [int] int CONSTRAINT [table_int_default] DEFAULT ((42)), [time] time CONSTRAINT [table_time_default] DEFAULT (cast('14:06:10' AS TIME)) ); ``` </Section> [source]
Name it as you wish and change the operator. This example allows for a numbers array, strings array, string, or even a select query. Feel free to create any other type you want or even contribute and submit a PR [source]
const table = singlestoreTable("table", { int: int("int").default(42), time: time("time").default(sql`cast("14:06:10" AS TIME)`), }); ``` ```sql CREATE TABLE `table` ( `int` int DEFAULT 42, `time` time DEFAULT cast("14:06:10" AS TIME) ); ``` </Section> [source]
<Card title="Prefix" href="./prefix" icon="phone"> Prefix search functionality </Card> </CardGroup> [source]
Nearest neighbors (NN) queries are popular for various AI-powered applications ([RAG](https://en.wikipedia.org/wiki/Retrieval-augmented_generation) uses NN queries to extract relevant information, and recommendation engines can suggest items based on embedding similarity). [source]
| Parameter | Default | Description | | --------- | -------------------- | ---------------------------------------------------------------------------------- | | `weights` | `1.0` for all fields | Comma-separated `column=weight` pairs. Higher weights increase score contribution. | [source]
Similar to `index_info` but includes additional columns. [source]
Another option is to duplicate the entire library. We could purchase 2 copies of every book and put them on 2 separate shelves: one shelf sorted by insertion time and another sorted by author. This would work, but it's expensive. We now need twice as much space for our library. [source]
First we make sure that the `price` attribute is indexed: [source]
1. Use the [`rs.stepDown()`](https://www.mongodb.com/docs/manual/reference/method/rs.stepDown/#mongodb-method-rs.stepDown) method in[`mongosh`](https://www.mongodb.com/docs/mongodb-shell/#mongodb-binary-bin.mongosh) to step down the primary. Upon successful stepdown, the current primary becomes a secondary and the replica set members elect a new primary. [source]
Indexes support efficient query execution in MongoDB to optimize query performance. [source]
Natural Language Querying translates natural language descriptions into MongoDB queries and aggregation pipelines using collection schemas and index information. [source]
Features such as read-only mode, telemetry, system use, and database index checks can be enabled or disabled individually. [source]
The keyword analyzer indexes multiple terms in a string field as a single searchable term and returns only exact matches. [source]
The multi object allows specifying alternate analyzers to index a field, enabling searches with either the default or alternate analyzer. [source]
The autocomplete field type indexes text values in string fields specifically for autocompletion and search-as-you-type applications. [source]
Boolean field types index true and false values, which can be queried with the equals and in operators or sorted by. [source]
Date field types index BSON date values and support querying with the range, near, in, and equals operators. [source]
The document field type indexes fields in objects or subdocuments with support for dynamic or static field mapping. [source]
The embeddedDocument field type indexes fields in documents or objects that are contained within an array. [source]
The geo field type indexes GeoJSON objects including polygons, MultiPolygons, LineStrings, and coordinate points for geospatial queries. [source]
The knnVector field type indexes vector embeddings for vector search using the knnBeta operator. [source]
The number field type indexes int32, int64, and double numeric values for querying with the equals, range, near, and facet operators. [source]
The objectId field type indexes BSON ObjectId values, allowing them to be queried or filtered using the equals and in operators. [source]
The stringFacet field type indexes string values in fields for facet search. [source]
The token field type indexes string values for sorting, faceting, and exact-match querying with the equals, in, and range operators. [source]
The uuid field type indexes BSON Binary Subtype 4 fields to filter or sort Atlas Search results by UUID values. [source]
The vector field type is used to index vector embeddings. [source]
The exists operator tests if a path to an indexed field name exists; if it exists but is not indexed, the document is excluded from results. [source]
Back up and restore mongot index data by using filesystem snapshots to minimize recovery time for self-managed Search and Vector Search deployments. [source]
Indexes can be used to improve query efficiency, including single field, compound, and geospatial types. [source]
MongoDB Vector Search queries can be run using the driver with support for various embedding types and auto-embedding indexes. [source]
Atlas Vector Search queries can be run using the MongoDB EF Core Provider with specific vector embedding types and index configurations. [source]
Indexes are used to improve query performance and support various operations like updates and deletes. [source]
Collations allow ordering query results by string values and can be specified for collections, indexes, and operations. [source]
Laravel Scout can be installed to index Eloquent models and implement full-text search capabilities within the application. [source]
The MongoDB\Collection class exposes methods for performing CRUD operations and index management. [source]
The MongoDB\Model\IndexInfo class exposes metadata about an index, including its key, name, namespace, version, and specific type flags. [source]
Collations should be used to apply language-specific rules for string comparison in collections, indexes, and operations. [source]
Indexes should be used to optimize query performance and improve efficiency. [source]
Geospatial queries involve storing data, creating indexes, and searching geospatial data. [source]
Develop effective indexing strategies by considering query types, read-write ratios, and memory usage. [source]
Identify application workloads by mapping frequent operations to optimize schema design and indexing for efficient database interactions. [source]
The `collMod` command modifies collection options or view definitions, including index properties, validation rules, and time series settings. [source]
The `compact` command releases unneeded disk space from a collection and its indexes back to the operating system. [source]
Indexes support efficient query execution in MongoDB. Learn how to create and manage indexes to optimize query performance. [source]
By using MongoDB as a vector database, you can use MongoDB Vector Search to seamlessly search and index your vector data alongside your other MongoDB data. Learn how to implement vector search in your applications. [source]
Translates natural language descriptions into MongoDB queries and aggregation pipelines. This skill uses collection schemas, sample documents, and index information to generate accurate, optimized queries. Supports complex operations like geospatial queries, text search, and multi-collection joins. Distinct from MongoDB Atlas Search and Vector Search (see Search and AI Recommendations skill below). [source]
* model and field names * relation names * mapped database names * defaults, indexes, and constraints * extension-backed column types [source]
Periodically review and refine your essential queries and verify that their tables are properly indexed, so those queries are less exposed to slowdowns from competing workloads. [source]
* Change the Prisma query shape * Add or adjust an index * Return fewer fields or fewer rows * Cache repeated work [source]
* Generating boilerplate for models, indexes, constraints, and relations. * Keeping the schema consistent by sticking to naming and other conventions. * Auto-completing model and field definitions based on common database patterns. * Suggesting relationships and field types based on naming conventions. [source]
Prisma ORM 3 changes how constraints and indexes are named: [source]
1. **Update Raw Queries**: Convert all `$queryRaw` calls to use template literals or switch to `$queryRawUnsafe`. 2. **Test Thoroughly**: Pay special attention to: * Relations and cascading deletes * JSON field operations * Any raw SQL queries * Custom constraints and indexes [source]
1. **Schema Changes** * Explicit `@unique` constraints for one-to-one relations * Enforced `@unique` or `@id` for one-to-one and one-to-many relations in MySQL/MongoDB * Scalar list defaults * Index configuration improvements * Better string literal grammar [source]
1. **Update Schema**: Review and update your schema to handle breaking changes 2. **Update Application Code**: Make necessary changes to your application code 3. **Test Thoroughly**: Test all functionality, especially: * One-to-one relations * JSON field operations * Raw queries * Index configurations [source]
This will update your schema with new capabilities like improved index configuration. [source]
The contract separates what your application models from how it is stored. The `domain` section describes models, fields, and relations; the `storage` section describes tables, columns, keys, and indexes (or collections and indexes for a MongoDB contract); each model's `storage` block bridges the two. Everything is grouped by namespace (on PostgreSQL, the schema, typically `public`). [source]
A UUID is wider than an integer and random UUIDs index a little worse, but independent services never collide and nothing is leaked. [source]
All target PostgreSQL. ParadeDB and Supabase are experimental (ParadeDB supports the `key_field` index option only so far). The rest ship with Prisma 8. Extension names link to each package's README on GitHub. [source]
An index or column mapping references a field the model does not declare (unknown field in the contract definition, or a Mongo model index over an undeclared field). Raised while lowering/building the contract. Meta: `modelName`, `fieldName`, `indexSignature`. [source]
A Mongo variant model declares an index that conflicts with the discriminator scope of its variant, or a SQL index option value is not a string, finite number, or boolean. Raised by the Mongo contract builder and the Postgres index DDL renderer. Meta: `variantName`, `indexLabel`, `reason`, `key`. [source]
Two declarations claim the same name: duplicate namespace entries, model names, value objects, relations, tables (two models mapping to one table, or duplicate table in a namespace), column mappings (two fields to one column), indexes, value-sets (enum and pack entity minting the same value-set), or pack entities of the same kind and name in one namespace. Raised while authoring/building a contract. Meta: `kind`, `name`, `namespaceId`, `first`, `second`. [source]
A foreign key or index references a table name that disagrees with the table the target model is actually mapped to. Raised while building a SQL contract. Meta: `sourceModel`, `referencedTable`, `mappedTable`. [source]
Query Insights is most useful for diagnosing N+1 patterns, missing indexes, over-fetching, offset pagination, and repeated queries. In most cases it points you toward one of four fixes: changing the Prisma query shape, adding or adjusting an index, returning fewer fields or rows, or caching repeated work. [source]
This creates an executable file named `index` (or `index.exe` on Windows) in your project directory. [source]
| Feature | Supported by Prisma ORM | Notes | | ----------------------------------------- | :---------------------: | :------------------------------------------------------------------------------------------------: | | Embedded documents | ✔️ | | | Transactions | ✔️ | [source]
* ¹ Can be required by some of the index and field types. [source]
> [!NOTE] > **MongoDB introspection limitations:** Prisma introspects MongoDB by sampling documents. You may need to manually: > > * Add relation fields using the `@relation` attribute > * Adjust field types if the sampling didn't capture all variations > * Add indexes and constraints not detected during introspection [source]
Currently, there are no plans to add support for [Prisma Migrate](https://www.prisma.io/docs/orm/v7/prisma-migrate) as MongoDB projects do not rely on internal schemas where changes need to be managed with an extra tool. Management of `@unique` indexes is realized through `db push`. [source]
Location: ORM > v7 > Prisma Schema > Data Model > Indexes [source]
The `sort` argument allows you to specify the order that the entries of the index or constraint are stored in the database. This can have an effect on whether the database is able to use an index for specific queries. The behavior and support varies by database: [source]
The following example demonstrates the use of the `sort` and `length` arguments to configure indexes and constraints for a `Post` model: [source]
As an example, the following model adds an index with a `type` of `Hash` to the `value` field: [source]
As an example, the following model configures a custom name for the index on the `title` field: [source]
**Capabilities** - Simplifies data access by precomputing complex expressions. - Enhances query performance with index support on generated columns. [source]
**Example** generated columns with full-text search <CodeTabs items={["schema.ts"]}> <CodeTab> ```typescript copy {17-19} import { SQL, sql } from "drizzle-orm"; import { customType, index, int4, cockroachTable, string } from "drizzle-orm/cockroach-core"; [source]
// `.on()` index('name') .on(table.column1.asc(), ...) .where(sql``) // sql expression [source]
<br/> <Flex> <LinksList title='Manage schema' links={[ ["Column types", "/docs/cockroach/column-types"], ["Indexes and Constraints", "/docs/cockroach/indexes-constraints"], ["Database Views", "/docs/cockroach/views"], ["Database Schemas", "/docs/cockroach/schemas"], ["Sequences", "/docs/cockroach/sequences"], ]} /> <LinksList title='Zero to Hero' links={[ ["Database connection", "/docs/cockroach/connect-overview"], ["Data querying", "/docs/cockroach/data-querying"], ["Migrations", "/docs/cockroach/migrations"], ]} /> </Flex> [source]
1. **You should specify a name for your index manually if you have an index on at least one expression** [source]
2. **Push won't generate statements if these fields(list below) were changed in an existing index:** [source]
If you are using `push` workflows and want to change these fields in the index, you would need to: [source]
1. Comment out the index 2. Push 3. Uncomment the index and change those fields 4. Push again [source]
For the `generate` command, `drizzle-kit` will be triggered by any changes in the index for any property in the new drizzle indexes API, so there are no limitations here. [source]
<CodeTabs items={["schema.ts", "migration.sql"]}> <CodeTab> ```ts copy {18,19,20,23} import { SQL, sql } from 'drizzle-orm'; import { index, pgTable, serial, text, customType } from 'drizzle-orm/pg-core'; [source]
<CodeTabs items={["schema.ts", "migration.sql"]}> <CodeTab> ```ts copy {18,19,20,21,22,23,24,28} import { SQL, sql } from 'drizzle-orm'; import { index, pgTable, serial, text, customType } from 'drizzle-orm/pg-core'; [source]
`PostGIS` extends the capabilities of the PostgreSQL relational database by adding support for storing, indexing, and querying geospatial data. [source]
This is how you can create table with `geometry` datatype and spatial index in Drizzle: [source]
<Prerequisites> - Get started with [PostgreSQL](/docs/get-started-postgresql) - [Select statement](/docs/select) - [Indexes](/docs/indexes-constraints#indexes) - [sql operator](/docs/sql) - You should have `[email protected]` and `[email protected]` or higher. </Prerequisites> [source]
```typescript // Index declaration reference index('name_idx') .on(table.name) .where(sql``) ``` [source]
<br/> <Flex> <LinksList title='Manage schema' links={[ ["Column types", "/docs/mssql/column-types"], ["Indexes and Constraints", "/docs/mssql/indexes-constraints"], ["Database Views", "/docs/mssql/views"], ["Database Schemas", "/docs/mssql/schemas"], ]} /> <LinksList title='Zero to Hero' links={[ ["Database connection", "/docs/mssql/connect-overview"], ["Data querying", "/docs/mssql/data-querying"], ["Migrations", "/docs/mssql/migrations"], ]} /> </Flex> [source]
**Capabilities** - Used in SELECT, INSERT, UPDATE, and DELETE statements. - Can be indexed, both virtual and stored. - Can specify NOT NULL and other constraints. [source]
Similar to one-to-one relationships, one-to-many relations benefit significantly from indexing to optimize join operations. Consider the "users and posts" example where one user can have many posts. [source]
Many-to-many relationships, implemented using junction tables, require a slightly more nuanced indexing strategy to ensure optimal query performance. Consider the "users and groups" example with the `usersToGroups` junction table. [source]
Let's take a few examples of `pg_vector` indexes from the `pg_vector` docs and translate them to Drizzle [source]
With the available Drizzle indexes API, you should be able to write any indexes for PostGIS [source]
- **Browse data** with pagination, filtering, multi-column sorting and column reordering - **Edit data** inline — add, update and delete rows, in-place editable `json`, `boolean` and `enum` editors - **Copy & paste** cell ranges, copy rows to clipboard or export them as `json`/`csv`/`sql` - **Import** `json`, `csv` and `sql` files - **Run SQL** in the SQL console with autocompletion, `explain`/`analyze` support and query telemetry - **Run Drizzle queries** with the Drizzle runner - **Explore and manage your schema** — tables, views, columns, indexes, foreign keys, policies and privileges [source]
* Preparing the data for storage and retrieval: Cleaning and structuring the data, chunking large texts, enriching it with additional information, indexing it for fast retrieval, etc. * Retrieval strategy: How to retrieve the most relevant documents for a given prompt. Techniques include semantic similarity using vector embedings, keyword matching, use of relation graphs, and combinations of these. And of course each technique has variety of algorithms and models with different strengths and different usage patterns. [source]
Probabilistic index that can be useful for columns with many distinct values. [source]
A Bloom index is most useful for queries that filter on multiple columns. You need to specify the indexed columns and configure the number of bits per column (`colN`): [source]
This index will allow efficient case-insensitive lookups. [source]
The [cube](https://www.postgresql.org/docs/current/cube.html) extension in PostgreSQL provides a data type for multi-dimensional cubes. It is useful for applications requiring vector operations, such as geometric data, multi-dimensional indexing, and scientific computing. Your Nile database arrives with `cube` extension already enabled, so there's no need to run `create extension`. [source]
This index improves performance for queries filtering cube data. [source]
* The `cube` type supports up to 100 dimensions by default. * It does not support operations like `+`, `-`, or `*` directly; you must use provided cube functions. * Indexing performance depends on the number of dimensions and the dataset size. [source]
The `cube` extension in PostgreSQL enables efficient storage and querying of multi-dimensional data. It is particularly useful for geometric and scientific applications where vector operations and spatial indexing are needed. [source]
The `emailaddr` extension in PostgreSQL simplifies email validation and storage while ensuring efficient indexing for lookup queries. [source]
The `h3` extension in PostgreSQL enables powerful geospatial indexing and proximity searches using the H3 hexagonal grid system. It is particularly useful for geospatial applications requiring efficient location queries. [source]
The `h3_postgis` extension in PostgreSQL enables seamless integration between **H3 spatial indexing** and **PostGIS geometry operations**, making it an excellent choice for advanced geospatial analysis and location-based applications. [source]
<CardGroup> <Card title="Bloom" href="./bloom" icon="filter"> Probabilistic index that can be useful for columns with many distinct values </Card> [source]
<Card title="H3" href="./h3" icon="hexagon"> Spatial indexing system developed by Uber </Card> [source]
* ISN types are stored efficiently as 64-bit integers internally * Validation and check digit calculation is performed on input * Indexes work efficiently with all ISN types * Conversion between formats (e.g., ISBN-10/13) is fast [source]
* `subpath(ltree, offset, len)`: Get subpath of ltree * `nlevel(ltree)`: Return number of labels in path * `index(ltree, ltree)`: Return position of second ltree in first * `text2ltree(text)`: Cast text to ltree * `ltree2text(ltree)`: Cast ltree to text [source]
* Use appropriate indexes based on your query patterns * Monitor path lengths as very deep hierarchies can impact performance * Consider denormalization for frequently accessed ancestor/descendant information [source]
* `LIKE`: Standard pattern matching * `%`: Similarity search operator * `=~`: Regular expression match with bigram index support [source]
1. **Storage and Indexing**: * Use appropriate pixel types for your data * Create spatial indexes on raster columns * Consider tiling large rasters [source]
<Tip> Nile includes `public.uuid_generate_v7()` which generates UUIDs with time-ordered lexicographically sortable strings. It is recommended to use this function for fields that are used in sorting and indexing. </Tip> [source]
[LlamaIndex](https://llamaindex.ai/) is a framework for building context-augmented generative AI applications with LLMs. It provides a wide range of functionality including data connectors, index building, query engines, agents, workflows and observability. Making it easy to build powerful RAG applications. [source]
We initialize the vector store and the index in the `__init__` method: [source]
Then to store the embedding in the Nile vector store, we do exactly what we did in the quickstart example - enrich the todo item with the tenant ID and insert it into the index: [source]
* **Efficient Storage**: `jsonb` is stored in a binary representation, making it more compact than `json`. * **Better Performance**: `jsonb` allows indexing, making it faster for querying and retrieval. * **Flexibility**: It supports a variety of operations like indexing, full-text search, and partial updates. * **Order Independent**: Key order is not preserved (unlike `json`), and duplicate keys are removed. [source]
Indexes in PostgreSQL enhance database performance by allowing faster retrieval of specific rows. They work like an index in a book, providing quick references to relevant data. Here are the main index types: [source]
| Extension | Version | Description | | ----------------------------------------------------------------------------- | -------- | --------------------------------------------------------------------------- | | [JSON](https://www.sqlite.org/json1.html) | Built-in | Work with JSON data in SQLite. | | [FTS5](https://www.sqlite.org/fts5.html) | Built [source]
* **`codebases`** registers each project root. A single database can index multiple codebases. * **`chunks`** stores individual semantic units extracted from source files — functions, structs, classes, impl blocks, etc. Each chunk has a `name`, `signature`, code `snippet`, line range, and optionally a vector `embedding`. The `chunk_key` is a unique identifier (e.g. `file_path::kind::name`) for upsert operations. * **`indexed_files`** tracks which files have been indexed and their content hashes, enabling incremental re-indexing — only changed files are re-processed. [source]
<Info> The `experimental: ["index_method"]` flag enables Turso's `USING fts` index syntax and the `fts_match()` / `fts_score()` functions. </Info> [source]
Turso provides an FTS index with weighted BM25 scoring that is separate from SQLite's `fts5` virtual tables. [source]
| Function | Storage | Best for | | ----------------- | ------------------------- | -------------------------------------------------- | | `vector32_sparse` | Non-zero values + indices | TF-IDF, bag-of-words, high-dimensional sparse data | [source]
$findTodo = $this->db->executeQuery("SELECT * FROM todos WHERE id = ?", [$index])->fetchAssociative(); [source]
if (!empty($findTodo)) { echo "Enter the new value: "; $todo = trim(fgets(STDIN)); $this->updateTodo($findTodo['id'], $todo); echo "To-Do updated.\n"; } else { echo "Invalid index.\n"; } } [source]
public function deleteTodo() { $this->listTodos(); echo "Enter the number of the To-Do to delete: "; $index = intval(trim(fgets(STDIN))); $findTodo = $this->db->executeQuery("SELECT * FROM todos WHERE id = ?", [$index])->fetchAssociative(); if (!empty($findTodo)) { $this->removeTodo($findTodo['id']); echo "To-Do deleted.\n"; } else { echo "Invalid index.\n"; } } } ``` </CodeGroup> </Step> [source]
Remember to create appropriate indexes for efficient vector operations and adjust vector dimensions as needed for your use case. [source]
Turso provides full-text search through the FTS index method. For the complete reference including query syntax, tokenizers, and scoring, see [FTS Functions](/sql-reference/functions/fts). [source]
Access individual elements using zero-based indexing. Returns NULL for out-of-bounds or negative indices. [source]
| Parameter | Type | Description | | ----------- | --------- | ---------------------------------------------------------------------------- | | `array` | BLOB/TEXT | The array to measure | | `dimension` | INTEGER | Optional. 1-based dimension index. Defaults to `1` (the outermost dimension) | [source]
| Parameter | Type | Description | | ----------- | --------- | ----------------------- | | `array` | BLOB/TEXT | The array to measure | | `dimension` | INTEGER | 1-based dimension index | [source]
| Parameter | Type | Description | | --------- | --------- | ------------------------------------------------- | | `array` | BLOB/TEXT | The source array | | `start` | INTEGER | Start index (zero-based, inclusive). NULL means 0 | | `end` | INTEGER | End index (exclusive) | [source]
Full-text search with Tantivy-powered FTS indexes, scoring, and highlighting [source]
Turso provides full-text search through custom FTS indexes and three SQL functions: `fts_match` for filtering, `fts_score` for relevance ranking, and `fts_highlight` for displaying results with matched terms highlighted. [source]
| Parameter | Type | Description | | ----------------------- | ---- | ----------------------------------------------------------------- | | `column1, column2, ...` | TEXT | One or more columns covered by an FTS index | | `query` | TEXT | The search query string (see [Query Syntax](#query-syntax) below) | [source]
| Parameter | Type | Description | | ----------------------- | ---- | ------------------------------------------- | | `column1, column2, ...` | TEXT | One or more columns covered by an FTS index | | `query` | TEXT | The search query string | [source]
This example walks through creating a table, adding an FTS index, inserting data, and running queries with scoring and highlighting. [source]
| Syntax | Meaning | | ------------- | ------------------------------------------------- | | `$` | The root element | | `$.key` | Object member named `key` | | `$[N]` | Array element at index `N` (zero-based) | | `$.key1.key2` | Nested object member | | `$.key[0]` | First element of an array inside an object member | | `$[0].key` | Object member inside the first array element | [source]
| Parameter | Type | Description | | ------------- | ------- | ----------------------------------- | | `vector_blob` | BLOB | The source vector | | `start` | INTEGER | Start index (zero-based, inclusive) | | `end` | INTEGER | End index (exclusive) | [source]
Returns one row for each index on the named table. [source]
Returns one row for each column in the named index. [source]
Controls where temporary tables and indexes are stored. [source]
Domains are transparent to the query engine for operations like ORDER BY, indexing, arithmetic, and aggregation. A domain column behaves exactly like a column of its base type, with the addition of input validation. [source]
Remove an index from the database [source]
Rebuild indexes from scratch [source]
The VACUUM statement rebuilds the database file to reclaim unused space, defragment tables and indexes, and reduce the file size. Two forms are supported: `VACUUM` rebuilds the current database in place, while `VACUUM INTO` writes a compacted copy to a new file without modifying the source. [source]
After bulk deletes or long-running workloads that leave indexes fragmented, `VACUUM` rebuilds the indexes and often improves scan speed: [source]
- [Commit Timestamp](/database/advanced/commit-timestamp.md): Efficient iteration using a strictly increasing sequence identifier. - [OCC and Atomicity](/database/advanced/occ.md): Optimistic concurrency control and transaction atomicity in Convex - [Schema Philosophy](/database/advanced/schema-philosophy.md): Convex schema design philosophy and best practices - [System Tables](/database/advanced/system-tables.md): Access metadata for Convex built-in features through system tables including scheduled functions and file storage information. - [Backups](/database/backup-restore.md): Backup and r [source]
From **`Cursor Settings`** > **`Indexing & Docs`** > **`Docs`** add new doc, use the URL "<https://docs.convex.dev/home>" [source]
The search expression must search for text in the index's `searchField`. The filter expressions can use any of the `filterFields` defined in the index. [source]
| Name | Type | Description | | ----------- | ------------------------------------- | ------------------------------------------------------------------------------------- | | `fieldName` | `SearchIndexConfig`\[`"searchField"`] | The name of the field to search in. This must be listed as the index's `searchField`. | | `query` | `string` | The query text to search for. | [source]
The field to index for full text search. [source]
The field to index for vector search. [source]
The length of the vectors indexed. This must be between 2 and 2048 inclusive. [source]
A type describing the ordered fields in an index. [source]
A type describing the indexes in a table. [source]
A type describing the document type and indexes in a table. [source]
Ƭ **Indexes**<`TableInfo`>: `TableInfo`\[`"indexes"`] [source]
The database indexes in a table for a given [GenericTableInfo](/api/modules/server.md#generictableinfo). [source]
Extract the fields of an index from a [GenericTableInfo](/api/modules/server.md#generictableinfo) by name. [source]
A [GenericDataModel](/api/modules/server.md#genericdatamodel) that considers documents to be `any` and does not support indexes. [source]
Ƭ **DocValidator**<`TableName`, `DocumentType`>: `DocumentType` extends [`VUnion`](/api/classes/values.VUnion.md)<`any`, infer Members, `any`, `any`> ? { \[Index in keyof Members]: WithSystemFieldValidators\<TableName, Members\[Index]> } extends infer NewMembers ? [`VUnion`](/api/classes/values.VUnion.md)<`WithSystemFieldValidators`<`TableName`, `Members`\[`number`]>\[`"type"`], `NewMembers`> : `never` : `WithSystemFieldValidators`<`TableName`, `DocumentType`> [source]
The indexes that Convex automatically adds to every table. [source]
Convex automatically appends "\_creationTime" to the end of every index to break ties if all of the other fields are identical. [source]
* The TypeScript type of this value. * Whether this field should be optional if it's included in an object. * The TypeScript type for the set of index field paths that can be used to build indexes on this value. * A JSON representation of the validator. [source]
5. Push your functions, [indexes](/database/reading-data/indexes/.md), and [schema](/database/schemas.md) to production. [source]
6. Push your functions, [indexes](/database/reading-data/indexes/.md), and [schema](/database/schemas.md) to the deployment. [source]
The "Delete table" button can be found by clicking on the `⋮` overflow menu at the top of the data page. This action will delete all documents this table, and remove the table from your list of tables. If this table had indexes, you will need to redeploy your convex functions (by running `npx convex deploy` or `npx convex dev` for production or development, respectively) to recreate the indexes. [source]
The "Indexes" button can be found by clicking on the `⋮` overflow menu at the top of the data page. [source]
This button will open a panel showing the [indexes](/database/reading-data/indexes/.md) associated with the selected table. [source]
Indexes that have not completed backfilling will be accompanied by a loading spinner next to their name. [source]
This [history page](https://dashboard.convex.dev/deployment/history) is an audit log of configuration-related events that have occurred in the selected deployment, such as function deployments, changes to indexes, and changes to environment variables. [source]
Selecting a table opens a side panel with more detail about that table, including the full type of each field and the table's [indexes](/database/reading-data/indexes/.md). From the side panel you can jump to a referenced table in the diagram, or open the table on the [Data page](/dashboard/deployments/data.md) to view and edit its documents. [source]
With an index on `db.vars.commitTs`, you do not need to worry about this, as the timestamp is strictly increasing. Since inserted documents will always have a greater commit timestamp, the tombstones will always end where the new documents begin. [source]
* Queries and mutations will not view intermediate states where partial data is imported. * Indexes and schemas will work on the new data without needing time for re-backfilling or re-validating. [source]
* Relational data modeling with [Document IDs](/database/document-ids.md) * Fast querying with [Indexes](/database/reading-data/indexes/.md) * Exposing large datasets with [Paginated Queries](/database/pagination.md) * Type safety by [Defining a Schema](/database/schemas.md) * Interoperability with data [Import & Export](/database/import-export/.md) [source]
In your query function, you can now filter your `messages` table by using the `by_channel` index. [source]
For a more in-depth introduction to indexing see [Indexes and Query Performance](/database/reading-data/indexes/indexes-and-query-perf.md). [source]
1. A name.  * Must be unique per table. 2. An ordered list of fields to index.  * To specify a field on a nested document, use a dot-separated path like `properties.name`. [source]
The `by_channel` index is ordered by the `channel` field defined in the schema. For messages in the same channel, they are ordered by the [system-generated `_creationTime` field](/database/types.md#system-fields) which is added to all indexes automatically. [source]
By contrast, the `by_channel_user` index orders messages in the same `channel` by the `user` who sent them, and only then by `_creationTime`. [source]
In addition to adding new indexes, `npx convex deploy` will delete indexes that are no longer present in your schema. Make sure that your indexes are completely unused before removing them from your schema! [source]
The order of the columns in the index dictates the priority for sorting. The values of the columns listed first in the index are compared first. Subsequent columns are only compared as tie breakers only if all earlier columns match. [source]
Since Convex automatically includes `_creationTime` as the last column in all indexes, `_creationTime` will always be the final tie breaker if all other columns in the index are equal. [source]
Sorting with indexes allows you to satisfy use cases like displaying the top `N` scoring users, the most recent `N` transactions, or the most `N` liked messages. [source]
For example, to get the top 10 highest scoring players in your game, you might define an index on the player's highest score: [source]
The `by_creation_time` index is created automatically (and is what is used in database queries that don't specify an index). The `by_id` index is reserved. [source]
This document explains how you should think about query performance in Convex by describing a simplified model of how queries and indexes function. [source]
1. Find the range of the index with entries for Jane Austen. 2. For each entry in that range, get the corresponding document. [source]
Now imagine that a patron shows up at the library and would like to check out *Foundation* by Isaac Asimov. Given our index on `author`, we can write a query that uses the index to find all the books by Isaac Asimov and then examines the title of each book to see if it's *Foundation*. [source]
`filter` on the other hand allows you to write arbitrary, complex expressions but it won't be run using the index. Instead, `filter` expressions will be evaluated on every document in the range. [source]
Unfortunately, Isaac Asimov wrote [a lot of books](https://en.wikipedia.org/wiki/Isaac_Asimov_bibliography_$alphabetical$). Realistically even with 500+ books, this will be fast enough on Convex with the existing index, but let's consider how we could improve it anyway. [source]
In this query, we're efficiently using the index to find all the books called *Foundation* and then filtering through to find the one by Isaac Asimov. [source]
In this case, the best option is probably to create the separate `by_title` index to facilitate this query. [source]
Congrats! You now understand how queries and indexes work within Convex! [source]
See [*Indexes and Query Performance*](/database/reading-data/indexes/indexes-and-query-perf.md) to learn more, and [*Using TypeScript to Write Complex Query Filters*](https://stack.convex.dev/complex-filters-in-convex) for more advanced filtering strategies. [source]
This type includes information about what tables you have, the type of documents stored in those tables, and the indexes defined on them. [source]
* **`function_execution`** — emitted after every query, mutation, action, and HTTP action. Use the resource fields (`database_io_read_bytes`, `database_io_write_bytes`, `execution_time_ms`, `action_memory_used_mb`, `file_storage_read_bytes`, `network_egress_bytes`, `vector_search_query_bytes`, `text_search_query_bytes`, etc.) to compute compute and bandwidth usage per deployment in real time. * **`current_storage_usage`** — periodic snapshots of total document, index, vector, text, file, and backup storage bytes. Use these to track storage usage per deployment over time. [source]
<Stack.Screen name="index" /> [source]
export default function Index() { [source]
1. 1 search expression against the index's search field defined with [`.search`](/api/interfaces/server.SearchFilterBuilder.md#search). 2. 0 or more equality expressions against the index's filter fields defined with [`.eq`](/api/interfaces/server.SearchFilterFinalizer.md#eq). [source]
* An array of numbers (e.g. embedding) to use in the search. * The search will return the document IDs of the documents with the most similar stored vectors. * It must have the same length as the `dimensions` of the index. [source]
For indexes with multiple filter fields, you can also use `.or()` filters on different fields. Here's a filter for dishes whose cuisine is French or whose main ingredient is butter: [source]
In this tutorial we just touched on the very basics. It's ok to just stop here and go explore the rest of the docs, including [efficient queries via indexes](/database/reading-data/indexes/.md) and traversing [relationships through joins](/database/reading-data/.md#join). If you're deeply curious about how Convex works, you can read this [excellent deep dive](https://stack.convex.dev/how-convex-works). [source]
Read through the [indexes documentation](/database/reading-data/indexes/indexes-and-query-perf.md) for an overview of how to define indexes and how they work. [source]
Using `$gt`, `$lt`, `$gte`, or `$lte` is supported on indexed attributes with checked types: [source]
✅ **Correction**: Use comparison operators on indexed attributes [source]
- Missing an index - Fetching or transacting too much data - Expensive `where` clauses - Expensive permission rules that traverse a lot of data [source]
Even if you're not using comparison operators or order clauses, indexing attributes can still speed up queries that filter by that attribute. [source]
The `where` clause supports comparison operators on fields that are indexed and have checked types. [source]
The `where` clause supports `$like` on fields that are indexed with a checked `string` type. [source]
Once you have a sense of how long your queries and transactions take, you can iteratively optimize them. For example, you can use pagination or add indexes to speed up queries, or break up large transactions into smaller ones. [source]
For broad context, start with https://motherduck.com/docs/llms-full.txt, then follow the most specific focused context link. Use https://motherduck.com/docs/llms-full-complete.txt only for bulk indexing or large-context workflows. [source]
- [Complete MotherDuck documentation](https://motherduck.com/docs/llms-full-complete.txt): Bulk indexing corpus (543 pages; 2,745,639 bytes; ~683,602 tokens). [source]
- The query is unsupported by your current indexes. - Some documents in your collection have large array fields that are costly to search and index. - One query retrieves information from multiple collections with [$lookup.](https://www.mongodb.com/docs/manual/reference/operator/aggregation/lookup/) [source]
The following options document specifies the `unique` option and the `name` for the index: [source]
The Atlas UI doesn't support building indexes with a rolling build for Free clusters and Flex clusters. [source]
MongoDB can also use the index to support a query on the `item` and `stock` fields, since the `item` field corresponds to a prefix. However, the index is not as efficient as `{ item: 1, stock: 1 }`. [source]
Without the `item` field, none of the preceding field combinations correspond to a prefix index. [source]
For example, the following operation creates a hidden ascending index on the `borough` field: [source]
The index option `hidden` is only returned if the value is `true`. [source]
For example, a collection has a unique single-field index on `email`: [source]
| Method | Description | |---|---| | | Drops a specific index from the collection. | | | Drops all removable indexes from the collection or an array of indexes, if specified. | [source]
The value of `nIndexesWas` reflects the number of indexes before removing an index. [source]
- To learn more about managing your existing indexes, see [Manage Indexes.](https://www.mongodb.com/docs/manual/tutorial/manage-indexes/#std-label-manage-indexes) - To learn how to remove an index in MongoDB Compass, see [Manage Indexes in Compass.](https://www.mongodb.com/docs/compass/current/indexes/) [source]
This page describes the types of indexes you can create in MongoDB. Different index types support different types of data and queries. [source]
Single field indexes collect and sort data from a single field in each document in a collection. [source]
This image shows an index on a single field, `score`: [source]
The index supports queries that select on the `test_scores` field. For example, the following query returns documents where at least one element in the `test_scores` array is greater than 90: [source]
The preceding query specifies a condition on both keys of the index (`item` and `ratings`). [source]
The following query uses the index on the `location` field: [source]
The index supports queries that select on the field `gpa`, such as the following: [source]
The index supports queries on the field `location.state`, such as the following: [source]
In the `wildcardProjection` document, the value `0` or `1` indicates whether the field is included or excluded in the index: [source]
You might want to query aspects of the `customFields` field for tenants that have a particular `tenantId`. You could create a series of individual indexes: [source]
This approach is difficult to maintain and you are likely to reach the maximum number of indexes per collection (64). [source]
The wildcard, `"customFields.$**"`, specifies all of the sub-fields in the `customFields` field. The other index term, `tenantId`, is not a wildcard specification; it is a standard field specification. [source]
The preceding command removes the `"tenant_customFields"` index from the `salesData` database. [source]
- For each subfield which is itself an object (for example, `account.contact` and`account.access` ), the index descends into the object and records its contents. - For all other subfields, the index records the primitive value into the index. [source]
Starting in MongoDB 6.3, 6.0.5, and 5.0.16, the `wildcardProjection` field stores the index projection in its submitted form. Earlier versions of the server may have stored the projection in a normalized form. [source]
- If the collection is empty, [`sh.shardCollection()`](https://www.mongodb.com/docs/manual/reference/method/sh.shardCollection/#mongodb-method-sh.shardCollection) creates the index on the shard key if such an index does not already exists. - If the collection is not empty, you must create the index first before using [`sh.shardCollection()`.](https://www.mongodb.com/docs/manual/reference/method/sh.shardCollection/#mongodb-method-sh.shardCollection) - If you reshard a collection using [`sh.reshardCollection()`](https://www.mongodb.com/docs/manual/reference/method/sh.reshardCollection/#mongodb-m [source]
Starting in MongoDB 7.0.3, 6.0.12, and 5.0.22, you can drop the index for a [hashed shard key](https://www.mongodb.com/docs/manual/core/hashed-sharding/#std-label-sharding-hashed-sharding). For details, see [Drop a Hashed Shard Key Index.](https://www.mongodb.com/docs/manual/tutorial/drop-a-hashed-shard-key-index/#std-label-drop-a-hashed-shard-key-index) [source]
Indexes can also partially support queries if a subset of the fields queried are indexed. [source]
Repeat this procedure periodically to ensure that your indexes support your current workload. [source]
| [1] | *([1](https://www.mongodb.com#ref-index-restriction-1), [2](https://www.mongodb.com#ref-index-restriction-2))* Some index types do not support collation. See[Collation and Unsupported Index Types](https://www.mongodb.com#std-label-collation-unsupported-index-types) for details. | [source]
The following indexes only support simple binary comparison and do not support [collation:](https://www.mongodb.com#std-label-collation) [source]
This example lists indexes for the `contacts` collection without specifying the cursor batch size. [source]
This example lists indexes for the `contacts` collection, and specifies a cursor batch size of 1. [source]
The following example returns all documents in the collection named `users` using the index on the `age` field. [source]
The query will use the index on the `price` field, even if the index on `_id` may be better. [source]
By specifying a collation `strength` of `1` or `2`, you can create a case-insensitive index. Index with a collation `strength` of `1` is both diacritic- and case-insensitive. [source]
The following options are available for [text](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-text/#std-label-index-type-text) indexes only: [source]
| Parameter | Type | Description | |---|---|---| | `bits` | integer | | | `min` | number | Optional. For `2d` indexes, the lower inclusive boundary for the longitude and latitude values. The default value is`-180.0` . | | `max` | number | Optional. For `2d` indexes, the upper inclusive boundary for the longitude and latitude values. The default value is`180.0` . | [source]
The following example creates an ascending index on the field `title`. [source]
The following operations, which use `"simple"` binary collation for string comparisons, can use the index: [source]
The following operation, which uses `"simple"` binary collation for string comparisons on the indexed `title` field, can use the index to fulfill only the `year: 2012` portion of the query: [source]
The index can support queries on any scalar field **except** those excluded by `wildcardProjection`: [source]
The following options are available for `2d` indexes only: [source]
| Parameter | Type | Description | |---|---|---| | `bits` | integer | Optional. For `2d` indexes, the number of precision of the stored[geohash](https://www.mongodb.com/docs/manual/reference/glossary/#std-term-geohash) value of the location data. The `bits` value ranges from 1 to 32 inclusive. The default value is`26` . | | `min` | number | Optional. For `2d` indexes, the lower inclusive boundary for the longitude and latitude values. The default value is`-180.0` . | | `max` | number | Optional. For `2d` indexes, the upper inclusive boundary for the longitude and latitude values. The default v [source]
The following example creates multiple indexes on the `cakeSales` collection: [source]
The first three indexes are on single fields and in ascending order (`1`). [source]
The last index is on `orderDate` in ascending order (`1`) and `state` in descending order (`-1`). [source]
In a `pets` collection, create a descending index on the `cat` field: [source]
Index information includes the keys and options used to create the index. The index option `hidden` is only available if the value is `true`. [source]
The difference between the number of matching documents and the number of examined documents may suggest that, to improve efficiency, the query might benefit from the use of an index. [source]
**Compare Performance of Indexes** [source]
In this example, the secondary that will build the new index is the third node in `cfg.members`. [source]
Connect directly to the [`mongod`](https://www.mongodb.com/docs/manual/reference/program/mongod/#mongodb-binary-bin.mongod) instance running as a standalone on the new port and create the new index for this instance. [source]
Connect [`mongosh`](https://www.mongodb.com/docs/mongodb-shell/#mongodb-binary-bin.mongosh) to a [`mongos`](https://www.mongodb.com/docs/manual/reference/program/mongos/#mongodb-binary-bin.mongos) instance in the sharded cluster and disable migrations for the collection where you want to perform the rolling build index: [source]
From the output, you only build the indexes for `test.records` on `shardA` and `shardC`. [source]
The [config server](https://www.mongodb.com/docs/manual/core/sharded-cluster-config-servers/#std-label-sharding-config-server) primary periodically checks for index inconsistencies across the shards for sharded collections. To configure these periodic checks, see [`enableShardedIndexConsistencyCheck`](https://www.mongodb.com/docs/manual/reference/parameters/#mongodb-parameter-param.enableShardedIndexConsistencyCheck) and `shardedIndexConsistencyCheckIntervalMS`. [source]
If MongoDB reads a relatively large number of documents to return results, some queries may perform faster without indexes. To determine performance, see [Measure Index Use.](https://www.mongodb.com/docs/manual/tutorial/measure-index-use/#std-label-indexes-measuring-use) [source]
An index can have multiple equality keys. They can appear in any order relative to each other, but all equality keys must precede any sort or range fields. [source]
MongoDB provides several ways to examine the performance of your workload, allowing you to understand query performance and identify long-running queries. Understanding query performance helps you build effective indexes and ensure your application runs critical queries efficiently. [source]
for the collection and its indexes The average size of documents | [source]
Queries on collections with indexes may not make effective use of the indexes. [source]
Compare the number of keys examined to the number of documents examined. If the number of keys is significantly less than the number of documents, it indicates the indexes were ineffective. [source]
- populates the missing fields into the inserted document - sets their values to `null` - adds an entry to the index [source]
/* Cleaning the collection */ db.users.deleteMany( {} ); // Delete only documents, keep indexes definitions db.users.insertMany( [user1, user2] ); /* Test */ db.users.updateOne( { _id: user1._id }, { $push: { accounts: account1 } } ); db.users.updateOne( { _id: user2._id }, { $push: { accounts: account1 } } ); [source]
/* Cleaning the collection */ db.users.deleteMany( {} ); // Delete only documents, keep indexes definitions db.users.insertMany( [user1, user2] ); // Re-insert test documents /* Test */ db.users.updateOne( { _id: user1._id }, { $push: { accounts: account1 } } ); db.users.updateOne( { _id: user1._id }, { $push: { accounts: account1 } } ); db.users.findOne( { _id: user1._id } ); [source]
/* Cleaning the collection */ db.users.drop( {} ); // Delete documents and indexes definitions db.runCommand( { collMod: "users", // update collection to use schema validation validator: accountsValidator } ); db.users.insertMany( [user1, user2] ); /* Test */ db.users.updateOne( { _id: user1._id }, { $push: { accounts: account1 } } ); db.users.updateOne( { _id: user1._id }, { $push: { accounts: account1 } } ); [source]
**Expand for example User model with a @@unique block** [source]
* Every record of a model must be *uniquely* identifiable. You must define *at least* one of the following attributes per model: * [`@unique`](#unique) * [`@@unique`](#unique-1) * [`@id`](#id) * [`@@id`](#id-1) [source]
* A model can have any number of `@@unique` blocks [source]
The name of the `fields` argument on the `@@unique` attribute can be omitted: [source]
> ```prisma no-lines > @@unique(_ fields: FieldReference[], name: String?, map: String?, where: raw(String) | { field: value }?) > ``` [source]
For example, in the following schema, `MailBox` has a composite type, `addresses`, which has a `@@unique` constraint on the `email` field. [source]
* In **relational databases**, the ID can be a single field or based on multiple fields. If a model does not have an `@id` or an `@@id`, you must define a mandatory `@unique` field or `@@unique` block instead. * In **MongoDB**, an ID must be a single field that defines an `@id` attribute and a `@map("_id")` attribute. [source]
Unique attributes can be defined on a single field using [`@unique`](https://www.prisma.io/docs/orm/v7/reference/prisma-schema-reference#unique), or on multiple fields using [`@@unique`](https://www.prisma.io/docs/orm/v7/reference/prisma-schema-reference): [source]
While Prisma ORM lets you place `@unique` and `@@unique` attributes on views, the underlying database and Prisma do not enforce those constraints. Multiple rows can therefore share the same value for a supposedly unique field. [source]
.withIndex("by_author", (q) => q.eq("author", identity.email)) [source]
> **Note**: Before the `partialIndexes` Preview feature, the signature was: > > ```prisma no-lines > @unique(map: String?, length: number?, sort: String?, clustered: Boolean?) > ``` [source]
export const users = pgTable( 'users', { id: serial('id').primaryKey(), name: text('name').notNull(), email: text('email').notNull(), }, (table) => [ // uniqueIndex('emailUniqueIndex').on(sql`lower(${table.email})`), uniqueIndex('emailUniqueIndex').on(lower(table.email)), ], ); [source]
export const users = mysqlTable( 'users', { id: serial('id').primaryKey(), name: varchar('name', { length: 255 }).notNull(), email: varchar('email', { length: 255 }).notNull(), }, (table) => [ // uniqueIndex('emailUniqueIndex').on(sql`(lower(${table.email}))`), uniqueIndex('emailUniqueIndex').on(lower(table.email)), ] ); [source]
export const users = sqliteTable( 'users', { id: integer('id').primaryKey(), name: text('name').notNull(), email: text('email').notNull(), }, (table) => [ // uniqueIndex('emailUniqueIndex').on(sql`lower(${table.email})`), uniqueIndex('emailUniqueIndex').on(lower(table.email)), ] ); [source]
▸ **vectorSearch**<`TableName`, `IndexName`>(`tableName`, `indexName`, `query`): `Promise`<{ `_id`: [`GenericId`](/api/modules/values.md#genericid)<`TableName`> ; `_score`: `number` }\[]> [source]
| Name | Type | | ----------- | ---------------------------------------- | | `TableName` | extends `string` | | `IndexName` | extends `string` \| `number` \| `symbol` | [source]
| Name | Type | | ----------- | ---------------------------------------------------------------------------------- | | `TableInfo` | extends [`GenericTableInfo`](/api/modules/server.md#generictableinfo) | | `IndexName` | extends [`VectorIndexNames`](/api/modules/server.md#vectorindexnames)<`TableInfo`> | [source]
| Name | Type | | ---- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `q` | [`VectorFilterBuilder`](/api/interfaces/server.VectorFilterBuilder.md)<[`DocumentByInfo`](/api/modules/se [source]
| Name | Type | | ----------- | ---------------------------------------------------------------------- | | `TableInfo` | extends [`GenericTableInfo`](/api/modules/server.md#generictableinfo) | | `IndexName` | extends [`IndexNames`](/api/modules/server.md#indexnames)<`TableInfo`> | [source]
Ƭ **NamedSearchIndex**<`TableInfo`, `IndexName`>: [`SearchIndexes`](/api/modules/server.md#searchindexes)<`TableInfo`>\[`IndexName`] [source]
| Name | Type | | ----------- | ---------------------------------------------------------------------------------- | | `TableInfo` | extends [`GenericTableInfo`](/api/modules/server.md#generictableinfo) | | `IndexName` | extends [`SearchIndexNames`](/api/modules/server.md#searchindexnames)<`TableInfo`> | [source]
Ƭ **VectorSearch**<`DataModel`, `TableName`, `IndexName`>: (`tableName`: `TableName`, `indexName`: `IndexName`, `query`: [`VectorSearchQuery`](/api/interfaces/server.VectorSearchQuery.md)<[`NamedTableInfo`](/api/modules/server.md#namedtableinfo)<`DataModel`, `TableName`>, `IndexName`>) => `Promise`<{ `_id`: [`GenericId`](/api/modules/values.md#genericid)<`TableName`> ; `_score`: `number` }\[]> [source]
▸ (`tableName`, `indexName`, `query`): `Promise`<{ `_id`: [`GenericId`](/api/modules/values.md#genericid)<`TableName`> ; `_score`: `number` }\[]> [source]
| Name | Type | | ----------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `tableName` | `TableName` | | `indexName` | `IndexName` [source]
| Name | Type | | -------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `runQuery` | (`name`: `string`, `args`?: `Record<string, Value>`) => `Promise<Value>` | | `runMutation` | [source]
- Run `db.collection.createIndex()` on the primary for a replica set - Run `db.collection.createIndex()` on the[`mongos`](https://www.mongodb.com/docs/manual/reference/program/mongos/#mongodb-binary-bin.mongos) for a sharded cluster [source]
The following example shows a `dropIndexes` event: [source]
[`dropIndexes`](https://www.mongodb.com#mongodb-dbcommand-dbcmd.dropIndexes) obtains an exclusive lock on the specified collection for the duration of the operation. All subsequent operations on the collection must wait until [`dropIndexes`](https://www.mongodb.com#mongodb-dbcommand-dbcmd.dropIndexes) releases the lock. [source]
| Field | Type | Description | |---|---|---| | `listIndexes` | string | The name of the collection. | | `cursor.batchSize` | integer | Optional. Specifies the cursor batch size. | | `comment` | any | Optional. A user-provided comment to attach to this command. Once set, this comment appears alongside records of this command in the following locations: [mongod log messages](https://www.mongodb.com/docs/manual/reference/log-messages/#std-label-log-messages-ref) , in the`attr.command.cursor.comment` field. [Database profiler](https://www.mongodb.com/docs/manual/reference/database-profiler/#std-la [source]
and) field. A comment can be any valid [BSON type](https://www.mongodb.com/docs/manual/reference/bson-types/#std-label-bson-types) (string, integer, object, array, etc). Any comment set on a `listIndexes` command is inherited by any subsequent[`getMore`](https://www.mongodb.com/docs/manual/reference/command/getMore/#mongodb-dbcommand-dbcmd.getMore) commands run on the`listIndexes` cursor. | [source]
If access control is enforced, the built-in [`read`](https://www.mongodb.com/docs/manual/reference/built-in-roles/#mongodb-authrole-read) role provides the required privileges to run [`listIndexes`](https://www.mongodb.com#mongodb-dbcommand-dbcmd.listIndexes) for the collections in a database. [source]
If the client that issued [`listIndexes`](https://www.mongodb.com#mongodb-dbcommand-dbcmd.listIndexes) disconnects before the operation completes, MongoDB marks [`listIndexes`](https://www.mongodb.com#mongodb-dbcommand-dbcmd.listIndexes) for termination using `killOp`. [source]
1 db.runCommand ( 2 { 3 listIndexes: "contacts", cursor: { batchSize: 1 } 4 } 5 ) [source]
The [`createIndex()`](https://www.mongodb.com#mongodb-method-db.collection.createIndex) method has the following form: [source]
The [`createIndex()`](https://www.mongodb.com#mongodb-method-db.collection.createIndex) method takes the following parameters: [source]
The [`db.collection.dropIndex()`](https://www.mongodb.com#mongodb-method-db.collection.dropIndex) method takes the following parameter: [source]
MongoDB\Collection::explain() analyzes command execution details including parameters and return values. [source]
The `explain` command analyzes execution plans for various MongoDB operations, including query planning and execution statistics. [source]
db.collection.explain() obtains query plan information for various MongoDB operations with options for verbosity levels. [source]
Familiarizing yourself with the [SQLite query planner](https://www.sqlite.org/queryplanner.html) can significantly enhance your understanding of how your queries are executed. This knowledge is pivotal in optimizing query efficiency. [source]
The EXPLAIN statement displays information about how Turso executes a SQL statement. There are two forms: `EXPLAIN` shows the virtual machine bytecode, and `EXPLAIN QUERY PLAN` shows the high-level query execution strategy. [source]
| Field | Description | |---|---| | reIndex | The name of the collection to reindex. | [source]
For MongoDB 5.0 or later, [`reIndex`](https://www.mongodb.com#mongodb-dbcommand-dbcmd.reIndex) may only be run on [standalone](https://www.mongodb.com/docs/manual/reference/glossary/#std-term-standalone) instances. [source]
[`reIndex`](https://www.mongodb.com#mongodb-dbcommand-dbcmd.reIndex) obtains an exclusive (W) lock on the collection and blocks other operations on the collection until it completes. [source]
` , MongoDB interprets`true` as`allPlansExecution` and`false` as`queryPlanner` .For more information on the modes, see [Verbosity Modes.](https://www.mongodb.com#std-label-explain-cursor-method-verbosity)The [`explain()`](https://www.mongodb.com#mongodb-method-cursor.explain) method returns a document with the query plan and, optionally, the execution statistics. [source]
Using `explain` ignores all existing plan cache entries and prevents the MongoDB query planner from creating a new plan cache entry. [source]
By default, [`cursor.explain()`](https://www.mongodb.com#mongodb-method-cursor.explain) runs in `queryPlanner` verbosity mode. [source]
[`db.collection.explain().find()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.explain/#mongodb-method-db.collection.explain) is similar to [`db.collection.find().explain()`](https://www.mongodb.com#mongodb-method-cursor.explain) with the following key differences: [source]
- The [`db.collection.explain().find()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.explain/#mongodb-method-db.collection.explain) construct allows for the additional chaining of query modifiers. For list of query modifiers, see[db.collection.explain().find().help().](https://www.mongodb.com/docs/manual/reference/method/db.collection.explain/#std-label-explain-method-help) - The [`db.collection.find().explain()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.explain/#mongodb-method-db.collection.explain) returns the`explain()` information on the que [source]
[`cursor.explain()`](https://www.mongodb.com#mongodb-method-cursor.explain) operations can return information regarding: [source]
tps://www.mongodb.com/docs/manual/reference/explain-results/#std-label-executionStats) , which details the execution of the winning plan and the rejected plans. - [`serverInfo`](https://www.mongodb.com/docs/manual/reference/explain-results/#std-label-serverInfo) , which provides information on the MongoDB instance. - `serverParameters` , which details internal parameters. [source]
For the database command, see the [`reIndex`](https://www.mongodb.com/docs/manual/reference/command/reIndex/#mongodb-dbcommand-dbcmd.reIndex) command. [source]
Explain plan results for queries are subject to change between MongoDB versions. [source]
1. Click the Explain Plan tab for the `test.inventory` collection. 2. Click Explain. [source]
Return to the Explain Plan tab for the `inventory` collection and re-run the query from the previous step: [source]
The [`explain()`](https://www.mongodb.com/docs/manual/reference/method/cursor.explain/#mongodb-method-cursor.explain) method returns the following output: [source]
For more information on optimizing queries, see [`explain`](https://www.mongodb.com/docs/manual/reference/command/explain/#mongodb-dbcommand-dbcmd.explain) and [Query Plans.](https://www.mongodb.com/docs/manual/core/query-plans/#std-label-query-plans-query-optimization) [source]
This task runs the [`explain()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.explain/#mongodb-method-db.collection.explain) method on a sample query in an attempt to identify performance issues. In practice, it may be difficult to run `explain()` on every query your application runs. [source]

Related concepts

index build — is a dependent of Indexing
index definition — is a part of Indexing
vector index — is a hyponym of Indexing; pgvector / Atlas Vector Search / Convex vector index — an index type, not the Pinecone sense
withIndex — is a instance of Indexing; Convex index API
text index — is a hyponym of Indexing; full-text/search indexes (Atlas Search, Convex search index, Postgres FTS)
unique constraint — is a near-synonym of Indexing; backed by a unique index in every engine here
@@index — is a instance of Indexing; Prisma schema index attributes
unique index — is a hyponym of Indexing
explain plan — is a related of Indexing
wildcard index — is a hyponym of Indexing
B-tree — is a hyponym of Indexing
GiST index — is a hyponym of Indexing; Postgres
compound index — is a hyponym of Indexing; MongoDB 'compound' = SQL 'composite'/'multicolumn'
GIN index — is a hyponym of Indexing; Postgres
IXSCAN — is a abbreviation of Indexing
partial index — is a hyponym of Indexing
geospatial index — is a hyponym of Indexing
collection scan — is a contrast of Indexing
query planner — is a whole of Indexing
index overhead — is a problem of Indexing

Children

← the whole tree · 3D view· how to read this page