Hacker News Reader

Comment by nicoburns | Hacker News Reader

The system I inherited at my current job was built with "scalability" in mind. That meant use of the Firebase databases and splitting everything out into lots of microservices. Ironically this actually caused scaling issues (even with the very small scale we have at the moment) because the lack of query flexibility in the database meant downloading entire collections in order to provide the necessary functionality.

We've since moved (almost) everything over to postgres and merged a lot of the microservice together. And while we're still running on heroku, we could probably run on Raspberry Pi if we needed to.

View on HN

It's incredible that with the increases in processing power and storage technology, and the continuous performance enhancements of postgres in particular the last years, any "scalable by design" solution of 10 or even 5 years ago can easily be implemented in postgres these days. I guess the 80/20 rule applies more than ever in these cases.

I am far from a database expert, but the fact that I have been able to implement without much effort efficient systems that have high bandwidth and reliability requirements, balancing and low latency speaks eons of the current state of affairs.

Sadly, I’ve seen this at more misguided startups. Microservices solve a problem no startup has until they go series B and grow like bananas. When they actually scale.

Sounds like it has nothing to do with microservices and more that they just blew everything up instead of fixing their firebase schema. But hey, sometimes that's way simpler.

Microservices didn't particularly cause technical issues. Just unnecessary operational overhead. While I'd probably go with a monolith if I was building for scratch, in this case we've stuck with ~5 microservices (we did have over 10) as it works well enough.

Firebase is fundamentally limited though. You simply cannot do things like joins and even filtering and updating is very limited compared to a SQL database. Of course you can implement these things in code, and precompute them and store them denormalised. But at that point you're implementing your own database and it's much less work to move the data to a different database platform. We did a gradual migration which made it relatively painless, although it was still a lot of work. And we're able to move much faster on new features now we have the flexibility of a fully-featured database.

firebase is probably the most hyped and overused tech I've seen. I've run into far too many startups that went to firebase because they wanted to scale fast and didn't realize how limited firebase was for queries.

If you're starting a startup, use postgres for your database. it will handle damn near anything and you can spawn off functionality into microservices as they become bottle necks as you scale.

Hell, postgres lets you write database extensions that perform novel behavior. I saw one the other day that automatically syncs data to elastic search. Wouldn't be that hard to envision having writes to certain tables sync to firebase if you need subscriptions on records for certain parts of your app.

Two reasons I use Firebase for my app (although with an admittedly trivial schema/data):

a) I have a thousand things to do that are higher priority than configuring/hosting a Postgres server. b) Integration with Firebase Auth is a godsend.

I doubt people choose Firebase for technical or scaling reasons. More likely they choose it because it's trivial to integrate, so you can spend the limited hours you have in each day on more important (customer-facing) work.

https://aws.amazon.com/rds/aurora/?aurora-whats-new.sort-by=...

https://www.heroku.com/postgres

https://cloud.google.com/sql/docs/postgres/

With all due respect, " they choose it because it's trivial to integrate" is a terrible reason for choosing a technology. Anyone choosing a database should be doing so based on the following.

1. does the insertion and querying mechanisms support the requirements of my app? 2. is it scalable? (ie first few thousand users, beyond that and any tech you pick is going to run into issues without a dedicated strategy) 3. can I afford it? (in terms of maintenance as well as licensing)

Postgres (and mysql) has plenty of standard tooling for integrating into your app and is no where near as limited. I would not take an engineer proposing firebase without making a STRONG logical case for why its the best choice as someone who's graduated out of junior status.

Then again, fixing messes caused by such engineers for several startups that started with firebase because its the easiest to get started with PAID for my galavanting around southeast Asia last year so I won't wag my finger too hard.

Postgres is also trivially integrated with firebase auth. There's a method in the client SDK which gives you a token you can send with API requests. And a method in the admin SDK that you can use to validate the token and resolve it to a user id.

a) You can choose managed PostgreSQL services.

b) Fine but it's too small reason to choose database for serious service, isn't it?

Reply on news.ycombinator.com