Implement live data updates in Bubble by understanding how auto-binding and WebSocket-based data refresh work, using Do a search for on page elements for automatic updates, forcing manual refreshes when needed, and optimizing real-time performance to avoid unnecessary data loads and workload unit consumption.
Overview: Implementing Live Data Updates in Bubble
This tutorial explains how Bubble handles live data updates. You will learn when data refreshes automatically, how to leverage auto-binding for real-time experiences, when you need to force manual refreshes, and how to optimize your app so live updates do not degrade performance or burn through workload units.
Prerequisites
- A Bubble account with an existing app
- At least one data type with records that change
- Basic understanding of Bubble data types and Repeating Groups
- Familiarity with Bubble workflows
Step-by-step guide
Understand Bubble's auto-refresh mechanism
Understand Bubble's auto-refresh mechanism
Bubble uses a WebSocket connection to detect database changes. When a record changes, any Do a search for on a page element (Repeating Group, Text, etc.) that includes that record automatically re-runs and updates the display. This happens without a page reload. However, searches inside workflows do NOT auto-update — only element data sources do. This distinction is critical for understanding when your data will refresh and when it will not.
Pro tip: Only searches directly assigned as element data sources auto-refresh. Searches in workflows, custom states, or conditional expressions do not.
Expected result: You understand that element-level searches auto-refresh but workflow searches do not.
Set up a Repeating Group with live data
Set up a Repeating Group with live data
Go to the Design tab and add a Repeating Group. Set its data type and data source to Do a search for [your data type] with appropriate constraints and sorting. Any time a record matching these constraints is created, modified, or deleted, the Repeating Group will automatically update. Test this by opening the app in two browser tabs — make a change in one tab and watch it appear in the other.
Expected result: Data changes made in one browser tab appear automatically in another tab viewing the same Repeating Group.
Force manual refreshes when needed
Force manual refreshes when needed
Some scenarios require manual refresh: when data is stored in a Custom State (which does not auto-update from the database), when using a filtered list that Bubble cannot detect changes for, or after a backend workflow completes. To force a refresh, use the Display list action on the Repeating Group with a new search, or set the Repeating Group's data source to a Custom State and update that state with a fresh search result after your workflow completes.
Expected result: You can manually trigger data refreshes for scenarios where auto-refresh does not apply.
Optimize real-time performance
Optimize real-time performance
Auto-refreshing searches consume workload units each time they re-run. For pages with many dynamic elements, this can add up. Optimize by: using constraints to narrow search results (fewer records = less data transferred), avoiding unnecessary searches (combine data into fewer searches), using Option Sets for static data instead of database searches, and limiting Repeating Group rows to what is visible. For pages that do not need real-time updates, consider using custom states loaded once on page load.
Pro tip: A page with 10 auto-refreshing searches will re-run all 10 whenever any matching record changes. Consolidate searches where possible.
Expected result: Your live data setup is optimized for minimal workload unit consumption while maintaining real-time updates where needed.
Build a real-time notification indicator
Build a real-time notification indicator
A practical example: add a notification badge that updates live. Create a Notification data type with recipient (User), is_read (yes/no), and message (text). On the header, add a Text element showing: Do a search for Notifications (recipient = Current User, is_read = no):count. This search auto-refreshes, so when a new notification is created for this user, the count updates immediately without any page reload. For complex real-time applications requiring sub-second updates, consider working with RapidDev.
Expected result: A notification badge updates automatically when new notifications are created for the current user.
Complete working example
1LIVE UPDATES — WORKFLOW SUMMARY2=================================34AUTO-REFRESH (automatic, no action needed):5 - Repeating Group data source: Do a search for ...6 - Text element content: Do a search for ...:count7 - Any element with a search-based data source8 → Updates via WebSocket when matching records change910DOES NOT AUTO-REFRESH:11 - Custom States (even if set from a search)12 - Workflow search results13 - Conditional expressions using searches14 - Filtered (:filtered) results1516MANUAL REFRESH PATTERNS:1718 Pattern 1: Re-display list19 Event: After backend workflow completes20 Action: Display list in Repeating Group21 Data source: Do a search for [fresh search]2223 Pattern 2: Update custom state24 Event: Button Refresh is clicked25 Action: Set state data_list = Do a search for ...2627 Pattern 3: Page refresh (last resort)28 Action: Go to page (same page)29 → Full page reload, loses custom states3031OPTIMIZATION:32 1. Use constraints to narrow searches33 2. Limit Repeating Group rows34 3. Use Option Sets for static data35 4. Avoid searches inside RG cells36 5. Cache data in custom states for non-real-time pages37 6. Monitor WU usage in Settings → Metrics3839EXAMPLE: Real-time notification badge40 Text element content:41 Do a search for Notifications42 (recipient = Current User, is_read = no):count43 → Auto-refreshes when new Notifications are createdCommon mistakes when building live updates in Bubble
Why it's a problem: Expecting custom states to auto-update when database records change
How to avoid: Use element data sources (Do a search for) for data that needs live updates. Reserve custom states for temporary UI state.
Why it's a problem: Adding too many auto-refreshing searches to a single page
How to avoid: Consolidate searches where possible and use custom states for data that does not need real-time updates.
Why it's a problem: Using :filtered on a Repeating Group and expecting live updates
How to avoid: Use server-side constraints instead of :filtered for data that needs to auto-refresh.
Best practices
- Use element-level Do a search for data sources for data that needs live updates
- Use custom states for data that only needs to load once per session
- Keep search constraints tight to minimize data transferred on each refresh
- Limit Repeating Group rows to reduce the amount of data that refreshes
- Monitor workload unit usage to catch unexpected spikes from auto-refreshing searches
- Use Option Sets for static data that never changes
- Test real-time behavior with two browser tabs open simultaneously
Still stuck?
Copy one of these prompts to get a personalized, step-by-step explanation.
I am building a Bubble.io app and need some elements to update in real time when data changes (like a chat or notification count) while keeping other elements static for performance. How does Bubble's auto-refresh work and how do I optimize it?
Set up live data updates for my app. Make the notification count and chat messages update in real time using element data sources. Keep the dashboard statistics loaded once via custom states to save workload units.
Frequently asked questions
How fast do live updates appear?
Typically within 1-3 seconds of the database change. This depends on server load and WebSocket connection quality.
Do live updates work on mobile browsers?
Yes. Bubble's WebSocket connection works in all modern mobile browsers. However, some mobile browsers may pause WebSocket connections when the tab is in the background.
Can I disable auto-refresh for performance?
You cannot disable it per element. Instead, use custom states loaded once on page load for data that does not need real-time updates.
Do auto-refreshing searches cost workload units?
Yes. Each time a search re-runs due to a data change, it consumes WUs. Pages with many auto-refreshing searches can accumulate significant WU usage.
Can RapidDev help optimize real-time performance?
Yes. RapidDev specializes in Bubble development and can help optimize your app's real-time data architecture for minimal WU consumption while maintaining responsive live updates.
Talk to an Expert
Our team has built 600+ apps. Get personalized help with your project.
Book a free consultation