[dcmatt]

"Overall, this migration proved to be a massive success" but their metrics shows this migration resulted in, on average, slower response times. Wouldn't this suggest the migration was not successful. Postgres can be insanely fast, and given the volume of data this post suggests, it baffles me that the performance is so bad.

[hobs]

For 80MB of data sqlite should also be insanely fast, 1s doesn't seem like a DB problem.

[agent001]

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

https://docs.github.com/en/repositories/working-with-files/m...

[zie]

And yet you didn't read what you are linking to. Also, the OP was already doing LFS, which fixes the issue Github is talking about.

So that's not the issue, I don't know what the OP's problems were with an 80MB file, but that is not the issue.

[TheAnkurTyagi]

fair point about the slower response times But Neon's not just any Postgres. They've got that whole serverless angle, which can be a game-changer for scaling and costs. Maybe the team's still figuring out how to optimize for that setup? Plus, with Neon, they probably ditched that whole SQLite-in-git headache.

[dcmatt]

Game changer for scaling and costs? It’s an 80 MB database that needs to get duplicated by n developers and a test and production instance. They could get away with a $200 beelink under a desk. I see no reason to prematurely scale. I would focus on making things fast and creating a “duplicate database” button so devs can work without interrupting prod