Merge, editor, and infrastructure improvements for larger apps

Hi everyone!

My name is Melissa, a member of the Success team here at Bubble.

Over the last few weeks, we’ve shipped a set of improvements aimed at customers running larger, more complex apps, particularly relevant to those on Growth, Team, and Enterprise plans. Here’s a rundown of what’s new.

Merge improvements

We’ve made merges faster and more reliable, with a particular focus on how merging affects collaboration for teams working across multiple branches.

The biggest change is that merges no longer block other developers the way they used to. Previously, a server-side merge held the entire app locked for its full duration, even while unrelated changes were happening in other branches. Now, locking is scoped to just the part of the merge that actually needs it, so your team can keep working in unrelated branches more reliably while a merge is in progress. This means that the changes you’re making in the editor are also saved to your app faster and more consistently.

A few other fixes worth calling out:

  • Merges on large apps are meaningfully faster (cutting merge time by ~30% in testing) since we now skip sections neither branch touched instead of comparing everything.

  • Fixed false conflicts on large workflow expressions, where one-sided edits were sometimes incorrectly flagged as conflicting.

  • Fixed favicon merge conflicts, so favicon differences are treated as a single change instead of conflicting character by character.

  • Large merges are more reliable, so non-conflicting change sets load as expected and the conflict window is able to display more conflicts to resolve than before.

Editor improvements

The editor is more responsive, especially on larger apps. We’ve made targeted fixes to how editor pages load into browser memory, with the biggest gains showing up on the slowest operations.

Some of what’s behind these improvements:

  • Increased the batch size used to fetch app data, cutting the time it takes to load the editor on large apps.

  • Reduced redundant work in plugin type lookups and issue-checking, cutting unnecessary reprocessing.

  • Improved memory management, only holding memory for as long as necessary.

Read replicas (private beta)

If you’re on a dedicated instance, you likely already run direct queries against your app’s database. Heavier analytics queries used to compete with your live app for the same database resources, which meant reporting or AI workloads could slow down production performance.

Read replicas solve this by giving you a second database that mirrors every change from production in real time. Point your analytics queries at the replica instead, and your live app’s performance stays untouched.

This is useful for things like pulling app data into an AI or analytics pipeline, or running heavier reporting queries, without adding load to your production database.

Read replicas are in private beta now, ahead of a full rollout to dedicated customers.

Enterprise Hub

The Enterprise Hub is a new dashboard for customers on dedicated environments, giving you one place to see the health and performance of your infrastructure.

From the hub, you can see:

  • Status and uptime: Your app’s public domain availability and the underlying server uptime, without needing to ask us to pull that information on your behalf.

  • Infrastructure health: Key metrics like application CPU, database CPU, and available memory, for more visibility into what’s happening in your environment.

  • Reporting and usage: Which pages are getting the most traffic, so you can connect infrastructure behavior back to actual usage.

What’s next

This is part of an ongoing push to improve reliability and performance for teams building larger, more complex apps. If you want to see any of this in more depth, Emmanuel covered it live during our August 27 AMA.

Feel free to ask questions or share your thoughts in the comments below!

— Melissa

@melissa.wang Great work on these updates! Are there any plans to introduce a formal Pull Request (PR) workflow similar to GitHub for team code reviews before merging?

Thank you, these updates are very reassuring and seam like amazing steps in the right direction as long as these changes do not affect stability of the editor.