Migrating from Supabase due to Prisma connection mishandling?
Hello Neon Community,
I’m exploring NeonDB as a potential solution for an application currently facing challenges with high traffic loads and extensive database connection usage via Prisma. Our main concerns revolve around effectively managing and scaling database connections during peak times. Given NeonDB’s serverless architecture and PostgreSQL compatibility, I’m curious about its performance under such conditions.
How does NeonDB handle scenarios with high concurrent connections and intense read/write operations?
Is there any built-in mechanism or recommended practice with NeonDB that can optimize connection pooling, especially when integrated with an ORM like Prisma?
Can you provide any insights or case studies where NeonDB has been successfully implemented in high-traffic environments?
Any guidance or experiences shared would be greatly appreciated as we consider transitioning to a more scalable database solution.
Thank you!
3 Replies
ratty-blush•2y ago
Hey!
PostgreSQL compatibilityJust to make sure we're on the same page, Neon IS Postgres, not just Postgres-compatible. You can choose your Postgres version when you create a database, you can run most extensions, etc... We've just separated out the storage and compute parts, similar to what BigQuery or Snowflake do for analytical dbs.
How does NeonDB handle scenarios with high concurrent connections and intense read/write operations?Every database has a direct connection URL (max concurrent connections vary based on size of db https://neon.tech/docs/connect/connection-pooling#default-connection-limits) and a pooled connection URL (limited to 10,000 concurrent connections https://neon.tech/docs/connect/connection-pooling )- Neon uses pgBouncer for the connection pooling. For intense reads and writes, Neon should behave exactly like standard Postgres. The only special reccomendation is to size your minimum compute size based on the size of your working dataset. https://neon.tech/docs/manage/endpoints#sizing-your-compute-based-on-the-working-set - in simple terms, make sure that the data you are querying heavily can be cached on your compute so that the system doesnt need to make an extra trip to storage.
Is there any built-in mechanism or recommended practice with NeonDB that can optimize connection pooling, especially when integrated with an ORM like Prisma?I think https://neon.tech/docs/guides/prisma#use-connection-pooling-with-prisma has the answers... For older versions of Prisma, defaulting everything to the pooled connection would cause issues with
prisma migrate dev but that should be resolved in Prisma 5.1.0 +sensitive-blue•9mo ago
Any resolution on this in doing something similar
eager-peach•8mo ago
@Ronnie Sandlin can you explain more?