what was bizarre in this article. I found it's a simple customer success story about Neon but I see the improvement came from caching and connection pooling but Neon looks promising because of its database branching feature, which made testing and development faster looks like
Neon(https://github.com/neondatabase/neon) seems to have helped them with testing and development. Being able to iterate and validate changes is a great benefit.
80MB is actually large enough to impact git performance according to Github. Imagine every single developer on the team having repo performance impacts bc of the db and how that compounds over time
Neon actually solved a bunch of problems here. Sure, 80MB might not seem huge, but in a git repo? Also, 80MB is actually large enough to impact git performance according to Github(https://docs.github.com/en/repositories/working-with-files/m...). That can be a pain, especially if you're updating it often. Neon let them ditch the whole 'DB-in-git' approach. No more slowing down the repo or worrying about it ballooning with every update. Plus, it probably made deployment and scaling way smoother. Sometimes the 'clever' solution isn't the best long-term, you know? Kudos to them for recognizing that and making the switch.
We're using Neon with an internal Kubernetes operator and we're incredibly happy with Neon's tech solutions and my company switched over to Neon from PlanetScale. In part for the ability to scale up/down easily and also so I could run multiple databases on the same cluster and Neon starts very quickly as well which is pretty awesome but I think they are not equivalent of each other. Neon is like a serverless Postgres database, while Supabase is a BaaS.