Building in public and trying to figure out my engineering dilemma
Hey everyone! A year ago, I quit my engineering job of seven years to try to build a start-up, Typogram. Recently in my journey, I had an engineering and cost dilemma.
I was trying to decide between two very similar products: Real-Time Database and Firestore. Sharing this here in case anyone else is trying to decide between these two products.
Most business offer product at different tiers - for example, for art supplies, there is professional or student tiers. These two products were very similar, and I was trying to make the most logistical decision.
Two things I thought of:
- Future Proofing
- Cost-effectiveness
Future-Proofing
Firestore is the more scalable option of the duo, while Real time promises some cool, nice-to-have features (like multiplayer) for my design tool.
Cost-Effectiveness
Firestore primarily charges for the number of reads and write requests. Realtime database primarily charges based on the data storage size. This is factor more difficult to estimate without our official launch. (right now, we are doing pre-orders).
After more research on reddit, I found out more ways to optimize the cost, and regarding the costs, it depends. For small apps with a small number of users (less than 150,000), you can use both and barely crack the free tier. Since cost-effectiveness question is out of the picture, I revisited the idea of multiplayer collaboration feature.
My Verdict
multiplayer is not a common use case for my start-up, at least right now. For now, I decide to keep using Firestore and revisit this dilemma in the future when Typogram reaches to stage that warrant a cost consideration for multiplayer features.
That's the end of my thinking out loud! If you enjoyed this post, I share my start-up journey weekly in my 🚧 build-in-public newsletter ⚒️. Subscribe if you feel like!
From my experience, Firebase in general was always a bad choice once I need to scale. While creating BuildGrowth, some ideas came up to my mind regarding real-time and I choose to go with Supabase, for example.
The thing with Firebase is that its vendor locked, so once you need to move your things out, well, you can't unless you create an export tool.
I had similar experience as well.
Every time I have these questions I share them on the #looking-for-feedback slack channel of the WBE Space. Most of the peeps there are engineers and they really help. With that said, as an entrepreneur I don't think to much long term. Just find a solution that works and its cheap and if your startup starts making money, then you can change it
In my experience, future proofing is almost always a bad idea. By definition, you don't know now what the future holds so trying to figure out what you're going to need is futile.
Cost effectiveness is important when you're just starting out but you've always got to be careful that you're not micro managing every last cent. Pick a budget you're comfortable with and go with the least friction option.
That said, if I was going to optimise for anything it would be change. In other words, your ability to try something else if the first decision isn't working out is more important than getting it right the first time.
I've heard nothing but good things about firebase. My old startup used it to host a medical trials search application. It seemed to get the job done. It's a bit tricky, though, once you've got thousands of users as the cost will increase, but you're bound to run into this problem with every similar provider and it's a good problem to have. If you don't have it now, I'd say thats a more important problem to solve then the one your currently facing about which service to go with.
You do know that both are just a database sitting behind some server right?
The cost and performance effective solution is to use neither. Firestore is just good for quick test. You don't want to actually use this in production due to cost and performance. Thing is migration out of firestore is so cheap that you can easily switch out.
Ask azure/aws engineers why they don't have similar technology offerings (They actually do /did, but killed because it's just not that great)