How to Load Test and Scale a Bubble Application

Before testing, map out the most common and important actions users take in your app. These typically include: page loads for your busiest pages, search operations, form submissions that create database records, and API calls to external services. For each flow, note the specific Bubble page URL or API endpoint URL. If your app has backend workflows exposed as API endpoints, include those too. Focus on flows that will experience the most traffic during peak usage.

Download and install k6, a free open-source load testing tool, from k6.io. Create a test script file that defines your test scenarios. For page load testing, use HTTP GET requests to your Bubble page URLs. For form submissions, use POST requests to your backend workflow endpoints. Define the number of virtual users (start with 10-20) and the test duration (2-5 minutes). k6 scripts are written in JavaScript and define scenarios that ramp up virtual users over time to simulate realistic traffic patterns.

Execute your k6 test script against your Bubble app. While the test runs, monitor two things simultaneously: the k6 output showing response times, error rates, and throughput, and your Bubble Logs tab showing server-side execution times and WU consumption. After the test completes, k6 provides summary metrics including median response time, 95th percentile response time, requests per second, and error percentage. Record these as your baseline.

Look for these warning signs in your results: response times above 3 seconds indicate slow pages or workflows, error rates above 1 percent suggest capacity limits, and response times that increase linearly with more users indicate a bottleneck that will worsen under load. In Bubble's Logs tab, check which workflows consumed the most WUs during the test. The highest-WU operations are your optimization targets. Common Bubble bottlenecks include: database searches with :filtered, searches inside repeating groups, complex conditional evaluations, and external API calls that add latency.

Use your test results to estimate capacity needs. If 20 virtual users cause acceptable response times but 50 users cause degradation, your current setup handles roughly 20-30 concurrent users. Multiply by your expected peak-to-average ratio (typically 3-5x) to determine the concurrent user capacity needed. Review Settings → App Metrics to see your WU consumption rate during the test. Calculate monthly WU needs by extrapolating: test WUs times expected daily active users divided by test users times 30. Compare against your plan's WU allocation to determine if you need to upgrade or add WU packages.