No, we’re not reevaluating our database, but since we launched Shoutouts, Supabase has been among the most shouted out products ever. If 2024 was the year of infra, @Supabase is at the forefront.
At the same time I’ve been hearing more about @Neon (17 shoutouts including several top-5 apps, like @Central (YC S24) ).
I’m curious: which did you choose (something else?) and why?
i tried both. both shine with their unique features.
@abdibrokhim Cool you've built on both! What did you learn from the experiences, any major (or minor!) takeaways?
I love Neon! Idk why more people don't talk about it. Easily create branches and revert back to a time in history if you accidentally drop tables or needed data. Also have one of the most generous free tiers and ui is very clean.
For me, the biggest factor is scalability. Neon's architecture with its cold storage and compute separation is promising for cost efficiency at scale. Supabase on the other hand is a great Firebase alternative.
Neon's branching caught my attention, but Supabase's ecosystem was too good to pass up.
Using both Supabase for the full backend experience and Neon for a few isolated DB-heavy workloads.
@eoin_bishop Interesting that you're using both. Can you share a bit more about when and why you use Neon? Is there any friction in using both of them in tandem?
We use Neon, but Supabase seems to be doing well.
Neon has one really cool trick, which is that you can fork the production database instantly. All of our team develops on their own copy of prod. It’s really good for debugging and fixing data issues. A second benefit we don’t need right now is instant scale up because compute and storage are separated
The downside is that local development can be slow since everything is using the cloud db. Also some types of admin are very difficult (like we are locked into certain versions of stuff)
Personal preference, but I don’t like the way supabase does things. It technically is Postgres, but really non-standard. I guess that goes with also trying to be a firebase replacement, as firebase was not built on a relational db. Neon is more standard postgres - same experience of using postgres, just with a different implementation under the hood. Our code wouldn’t change at all if we had to switch to RDS or something else.
Technically you can do the same with Supabase but that is not at all where their efforts are - If you wanted to do that you would not choose supabase.