News for hackers. Stuff that matters.

Ask HN: Why is the data transfer being used up so quickly?

I'm using Vercel to deploy my application, and Neon as the database. However, ever since I switched my SaaS to use SSR, the database data transfer has been consumed very quickly—around 2GB per day. Are there any good optimization methods? Or are there other databases I could use?
( 4 comments | on HN )
Re:Ask HN: Why is the data transfer being used up so quickly? by baobun on Monday May 26, 2025 @11:07PM (#44103627)
Measure, analyze, optimize.

You should be able to deploy your app locally, access it via a logging proxy, (say mitmproxy), and observe the logged HTTP traffic to identify what's going on. Pay attention to HTTP cache mechanisms.

Rinse and repeat until you are less than baseline (and if you don't/can't, is SSR really a good tradeoff for your use-case?).

Once you have verified your app behaves itself it's time to repeat on the cloud platform and address the public setup.

Re:Ask HN: Why is the data transfer being used up so quickly? by cebert on Monday May 26, 2025 @10:25PM (#44103418)
There are so few details here, it’s difficult for me to comprehend how you could expect anyone be able to provide any helpful advice. What troubleshooting and analysis have you done?
Re:Ask HN: Why is the data transfer being used up so quickly? by kristoff200512 on Tuesday May 27, 2025 @03:14AM (#44104637)
I checked the Vercel logs and found that many crawlers are scraping my pages, which leads to frequent database queries. Since Neon doesn't have caching, the data transfer is being consumed very quickly, and I'm currently using Prisma. Now I'm planning to migrate to Supabase and use supabase-js.
Re:Ask HN: Why is the data transfer being used up so quickly? by eampiart on Tuesday May 27, 2025 @03:38AM (#44104743)
(Prisma team member here)

Try Prisma Postgres: prisma.io/postgres

No data transfer costs at all, and built-in caching across 300+ global PoPs (still valuable to decrease latency): https://www.prisma.io/docs/postgres/database/caching