How to delete Single-field indexes that generated automatically by firestore?

Question

update:
TLDR;
if you reached here, you should recheck the way you build your DB. Your document(s) probably gets expended over time (due to nested list or etc.).

Original question:
I have a collection of documents that have a lot of fields. I do not query documents even no simple queries- I am using only-

db.collection("mycollection").doc(docName).get().then(....);

in order to read the docs, so I don't need any indexing for this collection.

The issue is that firestore generates Single-field indexes automatically, and due to the amount of fields cause limitation exceeding of indexing: And if I trying to add a field to one of the documents it throws me an error:

Uncaught (in promise) Error: Too many indexed properties for entity: app: "s~myapp",path <  Element {    type: "tags",    name: "aaaa"  }>
    at new FirestoreError (index.cjs.js:346)
    at index.cjs.js:6058
    at W.<anonymous> (index.cjs.js:6003)
    at Ab (index.js:23)
    at W.g.dispatchEvent (index.js:21)
    at Re.Ca (index.js:98)
    at ye.g.Oa (index.js:86)
    at dd (index.js:42)
    at ed (index.js:39)
    at ad (index.js:37)

I couldn't find any way to delete these single-field-indexing or to tell firestore to stop generating them. I found this in firestore console:

but there is no way to disable this, and to disable auto indexing for a specific collection. Any way to do it?

Answer 1

You can delete simple Indexes in Firestore firestore.

See this answer for more up to date information on creating and deleting indexes.

Firestore composite index permutation explosion?

If you go in to Indexes after selecting the firestore database and then select "single" indexes there is an Add exemption button which allows you to specify which fields in a Collection (or Sub-collection) have simple indexes generated by Firestore. You have to specify the Collection followed by the field. You then specify every field individually as you cannot specify a whole collection. There does not seem to be any checking on valid Collections or field names.

The only way I can think to check this has worked is to do a query using the field and it should fail.

I do this on large string fields which have normal text in them as they would take a long time to index and I know I will never search using this field.

Firestore creates two indexes for every simple field (ascending and descending) but it is also possible to create an exemption which removes one of these if you will never need the second one which helps improve performance and makes it less likely to hit the index limits. In addition you can select whether arrays are indexed or not. If you create a lot of entries it an Array, then this can very quickly hit the firestore limits on the number of indexes, so care has to be taken when using indexes and it will often be best to take the indexes off Arrays since the designer may have no control over how many Array data items are added with the result that the maximum index limit is reached and the application will get an error as the original poster explained.

You can also remove any simple indexes if you are not using them even if a field is included in a complex index. The complex index will still work.

Other things to keep an eye on.

If you are indexing a timestamp field (or any field that increases or decreases sequentially between documents) and you are not using this to force a sequence in queries, then there is a maximum write rate of 500 writes per second for the collection. In this case, this limit can be removed by removing the increasing and decreasing indexes.

Note that unlike the Realtime Database, fields created with Auto-ID do not guarantee any ordering as they are generated by firestore to spread writes and avoid hotspots or bottlenecks where all writes (and therefore reads) end up at a single location. This means that a timestamp is often needed to generate ordering but you may be able to design your collections / sub-collections data layout to avoid the need for a timestamp. For example, if you are using a timestamp to find the last document added to a collection, it might be better to just store the ID of the last document added.

Large array or map fields can also cause the 20,000 index entries per document limit to be reached, so you can exempt the array from indexing (see screenshot below).

Once you have added one exemption, then you will get this screen.

See this link as well.

https://firebase.google.com/docs/firestore/query-data/index-overview

Answer 2

The short answer is you can't do that right now with Firebase. However, this is a good signal that you need to restructure your database models to avoid hitting limits such as the 1MB per document.

The documentation talks about the limitations on your data:

You can't run queries on nested lists. Additionally, this isn't as scalable as other options, especially if your data expands over time. With larger or growing lists, the document also grows, which can lead to slower document retrieval times.

See this page for more information about the advantages and disadvantages on the different strategies for structuring your data: https://firebase.google.com/docs/firestore/manage-data/structure-data