Dwayne Charrington's photo

Hello, Firebasers.

Firstly, I just wanted to say how much I love Firebase and how grateful I am that Google hasn't sent it to the infamous graveyard where other beloved Google products have sadly gone. I've been using Firebase almost exclusively for the last four-and-a-half years.

I apologise for being greedy, but I have a few questions. Hopefully nothing too complicated that stumps your brilliant minds.

  1. Will there ever be a solution to the massive cold start issues with Firebase Functions? I realise they use Google Cloud Functions under-the-hood, but I've found unless I continually ping my functions to keep them warm, the startup time can be brutal.

  2. Are there any plans to add a cron feature into the Firebase interface? I know you can create crons through Google Cloud, but integrating them into Firebase can be tedious. I would love to be able to trigger cloud functions, perform actions in Firestore (clean old orphan data) and whatnot from Firebase Crons.

  3. GraphQL. Any plans to explore the possible use of GraphQL natively within Firebase? I've written GraphQL API's using Firebase Functions before, but I'd love to be able to map my Firestore database to a GraphQL layer of some kind without having to maintain it myself.

  4. Will you consider adding in the ability to configure caching? Right now, querying data in Firestore (even if it hasn't changed) results in being charged a read. It would be awesome if I could configure a cache strategy (document-by-document basis, even better) where I can specify content is cached for X amount of time (30 minutes or something) and any reads of cached data would not be counted towards usage.

  5. Any plans to introduce a non-NoSQL database option, something more akin to a traditional RDBMS like Postgres? Firestore is great, but it's not a perfect fit for all use-cases.

  6. Will pricing around Firestore ever be improved? Cost-wise, Real-Time Database is more cost-effective than Firestore. Perhaps considering a model which considers the storage size used of your documents and overall Firestore instead of going so heavy on read and write cost would be worth considering.

Samuel Stern's photo

Thanks for the Firebase love! Ok I'll try to give each question a short answer:

  1. The team is working hard to improve cold starts right now but they'll likely always be an issue. Cloud Run is the future here, it has min instances and concurrency.
  2. We already have scheduled functions!
  3. No plans to invest in GraphQL right now, although we do notice the enthusiasm.
  4. Probably not that exactly but we are working on a way for Firestore developers to cache results to common queries.
  5. Nothing in the works right now!
  6. Probably not going to change, it's likely Firestore will always charge based on operations. I wouldn't say RTDB is always less expensive though. If you have a large data set (hundreds of GBs) you're going to pay much much less for storage on Firestore!