Hi Supabase Team and Community,
I am in the architectural planning phase for a high-end luxury brand's contest website. We are planning to use the Pro Plan, but before we kick off the project, I need to verify the platform's limits regarding a specific high-traffic event scenario.
The Event Scenario:
Nature of Event: A "First 100 fastest" contest. We expect a sudden burst of traffic at the exact moment the event opens.
Expected Load: Approximately 2,000 real users performing the following actions within a 1-2 minute window:
Auth: Registering or logging in (via Phone Number).
Database: Inserting a record into a submissions table (Name, Phone, Agency_ID).
Storage: Uploading one image (~1MB after client-side compression).
Anonymous Traffic: At the same time, many other users will be hitting public API endpoints (PostgREST views) to see the "Live Leaderboard" and "Submission Gallery."
My Questions:
Rate Limits: Since this is a new project on the Pro Plan, will the default Rate Limits for Auth and PostgREST accommodate 2,000 users in such a short burst? If not, is it possible to request a temporary increase for the event day?
Compute Sizing: We understand Pro comes with dedicated compute. To avoid database locking during 2,000 concurrent inserts, would you recommend scaling up to a Small or Medium instance just for the launch window?
DDoS vs. Legitimate Burst: How does the platform distinguish between a DDoS attack and 2,000 legitimate users from the same region/ISP hitting the API at once?
Storage Throughput: Are there any known bottlenecks when 2,000 concurrent uploads happen? We plan to use client-side compression to keep files under 1MB.
I want to ensure a "zero-downtime" experience for my client. Any insights on how to "bulletproof" this setup during the preparation phase would be immensely helpful!
(Note: Project hasn't been created yet, this is for feasibility study/pre-sales confirmation)
The user is planning a high-traffic event for a luxury brand's contest website and is concerned about Supabase Pro's ability to handle 2,000 concurrent actions. They are seeking advice on rate limits, compute sizing, distinguishing legitimate traffic from DDoS attacks, and storage throughput. The user intends to contact Supabase support for further guidance and is considering temporary CPU scaling for the event.
Not going to even guess at your load as it is too dependent on the queries you run and normally you would need to benchmark.
2000 signups in a couple of minutes would be the biggest risk IMO. You probably need to contact Supabase and see what they think. I've never seen anyone need 2000 signups in 2 minutes. The docs have a rate limit section for auth with max settings but the load is also a factor as most are 10min to hour type settings.
Next would be storage.
Public table reads should not be an issue.
Check out the CPU sizing info in pricing and other spots for sizes. You can create a very large Pro instance and can upgrade to a very large instance for an even and then down grade after (with some minimal down time).
Otherwise just have to see if some users have done anything close.
Thanks for the insight! To clarify why we expect such a burst: The contest offers a special prize for the first 100 users to successfully submit their entries.
While the total traffic might not hit exactly 2,000, we are realistically expecting at least 1,000+ concurrent users racing to be in that Top 100. This 'FOMO' effect is what creates the massive spike in Auth and Storage requests at the exact opening second.
I will definitely follow your advice to contact Supabase support directly to whitelist our project and will look into temporary CPU scaling (Large instance) for the launch window.
Thanks for the insight! To clarify why we expect such a burst: The contest offers a special prize for the first 100 users to successfully submit their entries.
While the total traffic might not hit exactly 2,000, we are realistically expecting at least 1,000+ concurrent users racing to be in that Top 100. This 'FOMO' effect is what creates the massive spike in Auth and Storage requests at the exact opening second.
I will definitely follow your advice to contact Supabase support directly to whitelist our project and will look into temporary CPU scaling (Large instance) for the launch window.