What is load testing?

What can load testing tell you before a launch?

A prototype has never had more than a few people on it at once. Launches, press and waitlists do not ramp gently: they arrive at once. Load testing tells you in advance whether the database, the queue and the third-party limits hold, and which one gives out first.

How do load, stress, spike and soak tests differ?

They differ in the traffic they send. A load test sends expected traffic to confirm normal performance, a stress test goes beyond it to find the breaking point, a spike test sends a sudden surge like a launch, and a soak test holds steady traffic for hours to find leaks and slow drift.

• Load test: expected traffic, to confirm normal performance.
• Stress test: beyond expected traffic, to find the breaking point.
• Spike test: a sudden surge, like a launch.
• Soak test: steady traffic for hours, to find leaks and slow drift.

How is a load test shaped and run?

A load test ramps virtual users up gradually, holds them at the expected level, then ramps down. Grafana's k6 guide suggests a ramp-up of about 5 to 15 percent of the test's length and a hold at least five times longer than the ramp-up. Its example ramps to 100 users over five minutes and holds for thirty.

k6 recommends starting with a smoke test: a few users for a short time, to check the script works and the system responds. Then run the average-load test, and only then stress, spike or soak patterns. Watch for response times creeping up as load rises, and for stable performance and resource use while it holds.

How do you load test a Lovable and Supabase app safely?

Test a staging environment rather than production, script the journeys real users take at launch, expect the database to give out first, and check the limits of outside services, such as email and payment providers, before sending them test traffic. The list below explains why each step matters.

• Test a staging environment, not production, so test traffic never reaches real customers or their data.
• Script the journeys real users take at launch, such as sign-up and the core action, not just the home page.
• Expect the database to give out first: slow queries without a database index are a frequent cause.
• Check the limits of outside services, such as email and payment providers, before sending them test traffic.

The common mistake is testing a static page and calling the app ready. A home page served from a cache says little about sign-ups writing to the database at the same moment: the hard part is the database, the queue and the integrations behind it. If a launch is close and nothing has been tested, our vibe coding rescue covers it.