Comment by alanlamm | Hacker News Reader

Comment by alanlamm | Hacker News Reader

Paying Firestore user here.

1. Disappointing that it has gone to GA without providing proper search (after a long beta). Can anybody explain why a service run by the worlds #1 search company continues to point users to third party services if you want to implement a basic text search in a database? I genuinely don't understand that.

2. Feature requests (or complaints) re backup, queries and documentation are not new. Nor are the answers (or excuses) we see here, which revolve around scalability and (until now) being in beta. BUT all users I have ever heard say they use the product for speed & ease of setup & convenience - for MVPs, not for massive googlesque data. It almost feels like the product market fit is not quite right. So, forgive my technical ignorance here, but worst case scenario, why not provide the features with the caveat that they are slow or expensive or won't work above a certain size of db? Isn't half a solution better than no solution?

The database and whole Google/Firebase app suite thing has some strong points. But to be frank, and I'm sorry if I'm being dismissive of hard work and technical wonders here, from the perspective of a customer and outside observer, a number of things smell quite off.

Thank you for being a paying user.

1. Mainly because it's both a different search problem (general DB vs specific to web search) and hard engineering wise given our model; we implement not only the cloud database, but embedded versions for iOS, Android, and Web - not to mention real-time functionality and tailoring it to how our index engine works, etc. While we have a lot of customers and use-cases that don't need Fulltext Search, we totally agree it's important and have done explorations on how we'd deliver something along these lines.

2. Agreed. During the beta program we've delivered the managed export and import service for backups, adding array contains capabilities to queries and have got close enough to delivering Collection Group queries to mention them as part of GA. For documentation our tech writing team as done a lot of updates, new pages, and fixes - we know there is always more to do. Cloud Firestore is definitely used in production and at scale by our customers, and with nearly 1 million databases being created the range of use cases and traffic/load patterns has been vast. Our beta program involved working with a lot of them to improve things like hardening and scalability to ensure we can meet our 5 nines of availability SLA.

"Isn't half a solution better than no solution?" -> In a lot of cases, absolutely not. A half solution that falls over when you tip a certain point of scale can result in extended downtimes, since the solution often ends up being "we need to completely rearchitect this", which isn't easy or quick when your business is out of commission.

"from the perspective of a customer and outside observer, a number of things smell quite off." -> Sorry to hear this, I can only hope the continued hard work from the team will turn you around.

Thank you for the answer. I have to admit it doesn't quite sway me, for reasons such as those below, but thank you.

e.g. yes I realise they are different search problems, but I'd presume that Google is nonetheless well-equipped to handle the document db one. the only apps I can imagine that couldn't benefit from a search box are games - anything content-focused or ecommerce focused needs one, and the majority of utilities benefit too (yes I can do chat without search, but it certainly benefits from being able to search through chats) - any examples? yes I realize having to do Backend/iOS/Android/Web is hard (as it is for everybody else), but with on device cases at least the db is smaller. Im sure you do have big users, I didn't mean to imply otherwise, but with my admittedly very limited knowledge I'd still wager that a majority do not see uptime and scalability as the most urgent improvements, but rather those we are discussing. In our case, give us just 2 9s of uptime, and give us the above queries and searches even if 2x as slow and expensive as you'd like them to be, and limited to a db the size of an average relational db, and that would beat the extra 3 9s of uptime and the super scalability any day. Not least because, I don't mean to be rude here, just candid, but if we were ever to reach a point where we needed that massive scale and uptime, I'm not sure I'd be keen to trust Google with user data.

To be clear - I like several things about Firebase/Firestore, which is why we use it and why I'm insisting on badgering you here. I just wish I could be completely comfortable with my choice rather than wondering every day if I shouldn't just use something else.

They keep promoting Algolia. Actually once of the firebase engineer mentioned why to build search when already Algolia solves it. I was like, wow.

Yep, also disappointed to see it in GA missing queries and back ups. Makes it a non-starter for most folks.

Curious - what do you use? any suggestions of good serverless NoSQL? with the built in auth and extras Google/Firebase offer? What about relational? I've used Back4App, but with it being small and FB having killed Parse, it wasn't right.

Have you looked at Sanity [1]? You get both a fast cloud backend (with a powerful GraphQL-like query language with joins, transactions, object-level security, text matching, real-time change notification, etc.) and a collaborative editing front end (optional, but recommended!). The latter is open source and modular. You can deploy serverless just like Firebase/Firestore. Gatsby is a popular way to serve Sanity.

Disclosure: I've contributed to their database tech, but I don't work for Sanity. Mostly just a fan.

[1] https://sanity.io/

Check here: https://cloudbackend.appdrag.com

I'm looking at FaunaDb very closely, seems like a nice "all you might ever need", but a bit unfamiliar at first glance.

Reply on news.ycombinator.com