2

I'm creating an app where I will store users under all postalcodes/zipcodes they want to deliver to. The structure looks like this:

postalcodes/{{postalcode}}/{{userId}}=true

The reason for the structure is to easily fetch all users who deliver to a certain postal code. 

ex. postalcodes/21121/

If all user applies like 500 postalcodes and the app has about 1000 users it can become a lot of records:

500x1000 = 500000

Will Firebase easily handle that many records in data storage, or should I consider a different approach/solution? What are your thoughts?

Kind regards, Elias

Tiago Mussi
  • 801
  • 3
  • 13
  • 20
Elias
  • 111
  • 1
  • 8
  • 1
    The primary consideration is bandwidth--how many bytes you have to transfer over the internet--just as with any other web based service. The number of nodes is much less consequential than the total payload of data. Connections and overheads with Firebase are very small. – Kato Mar 07 '15 at 06:08

1 Answers1

12

I'm quite sure Firebase can return 500k nodes without a problem.

The bigger concerns are how long that retrieval will take (especially in this mobile-first era) and what your application will show your user based on that many nodes.

A list with 500k rows is hardly useful, so most likely you'll show a subset of the data.

  1. Say you just show the first screenful of nodes. How many nodes will that be? 20? So why would you already retrieve the other nodes already in that case? I'd simply retrieve the nodes needed to build the first screen and load the rest on demand - when/if needed.
  2. Alternatively I could imagine you show a digest of the nodes (like a total number of nodes and maybe some averages per zip code area). You'd need all nodes to determine that digest. But I'd hardly consider it to task of a client application to determine the digest values. That's more something of a server-side task. That server could use the same technology as client-apps (i.e. the JavaScript API), but it wouldn't be bothered (as much) by bandwidth and time constraints.

Just some ideas of how I would approach this, so ymmv.

Frank van Puffelen
  • 565,676
  • 79
  • 828
  • 807
  • Thanks for your thoughts @frank My concern here isn't returning all nodes, it's just storing them. Based on your respons i believe that isnt an issue. The app im building will fetch all users in a certain zip code, and a zip code will have max 200 users, and from every user i will fetch about 20-50 products, so returning data shouldn't be a problem. Based on the structure i store the data, i dont need to go thrue all nodes to get what i want. – Elias Mar 04 '15 at 15:52