4

My question is basically as stated in the title. I am examining using Firebase for our app backend (and an accompanying Nodejs server to take care of a couple of things that Firebase can't handle since it doesn't support Webhooks). I have an expectation that our database will contain millions of records - tens of thousands of users, thousands of a specific entity type and tens of thousands of records per each of those entities. While I do think the data can be flattened to simpify and speed queries, I am worried that Firebase is really not designed for a datastore of that size.

Does anyone have experience with huge datastores in Firebase and can offer some insight here?

Patrick Sears
  • 328
  • 4
  • 8
  • This answer may help: http://stackoverflow.com/a/16240601/754604 – Connor Pearson Jan 18 '14 at 22:11
  • 2
    My question isn't a duplicate because that question was asking about FORGE, which is the Firebase data viewer. However yes, someone did address the core issue, which is how Firebase itself performs under large data sets so I accept the answer. Thanks. – Patrick Sears Jan 19 '14 at 22:28
  • Yeah. In general, this was a BAD "Marked as Duplicate"; I already found the "duplicate" in a search and immediately dismissed it as off-topic since it specifically covered "FORGE" – Jay Stevens Dec 19 '14 at 15:40

1 Answers1

-7

Tens of thousand is not really huge for a relational database. We used Firebird with tables containing about 200,000 records. As long as you access your records through indexed fields and avoid table scans you should be fine. Also put as much RAM as possible into the DB server.

scraatz
  • 419
  • 2
  • 7
  • Not firebird, firebase - firebase.com. Also, it isn't a relational database. Essentially I'm expecting millions of records (tens of thousands times tens of thousands, that would of course be years from now but 100,000 is reasonable in the next 6 months). – Patrick Sears Jan 18 '14 at 20:20