Based on this answer which states:

It creates some indexes ahead of time, but you need to tell it when you want to query with nested children with orderByChild orderByValue.

Does this mean that the DB multiplies the branch for each .indexOn rule added 1?

eg:- I have 3 Megs of data on branch A which is indexed by $key.

If I use a rule:

"A": {".indexOn":["fieldA", "fieldB"]}

Now under the hood Firebase will Create a subbranch of A that will re-insert the indices already found on 'A' but this time under the key defined in the .indexOn rule:

A--|
   |__rule_field_a
          |
          |_val_of_field_a_1 -> :value_a
          |
          |_val_of_field_a_2 -> :value_b
          |
          etc... etc...

This means that the 2 indexOn rules will multiply the volume of the branch from 3 to 9 Megs.

Is this correct?

Will this get reflected in the pricing?

CodePudding user response：

firebaser here

Indexes that you define on the Firebase Realtime Database inside your security rules are not stored in your database itself, and you are not charged for them.

If you choose to store such data in the database yourself, you will of course be charged for that. An example of such a use-case would be Firebase query if child of child contains a value, but while that is commonly referred to as a reverse or inverted index, it is not declared in your security rules.