U can save money while building with Bubbleio

[SAIDER1]

Hello bubbleio devs, this is a 3 min reading subject that will change the way u use Repeating Groups.

Let me first explain something :

What are work units in Bubble?

Bubble charges work units (WUs) for every server-side action that processes or transfers data.

These WUs are not about how many workflows you run, but how much data Bubble has to fetch, process, and send.

Examples of actions that consume WUs:

Database queries (Do a Search for…)

Filtering / sorting data on the server

Loading large listsHow Repeating Groups consume WUs

Repeating Groups (RGs) are data-bound components. When you set an RG’s data source to something like:

Do a search for Products: filtered

this is what happens:

Initial load — Bubble queries your database and sends the first batch of results to the browser.

WUs consumed here.

Scrolling or pagination — If your RG uses “Ext. vertical scrolling” or you navigate to a different page of results, Bubble runs another database query to get the next set.

WUs consumed again.

Filtering / sorting — Even if the filter is small (e.g., only “Category = Books”), Bubble re-runs the search on the server side.

WUs consumed again.

Dynamic updates — If your page setup re-triggers the search (e.g., when an input changes), Bubble starts over, fetching from the DB again.

WUs consumed again.

The more times your RG’s “Do a search for…” runs, the more WUs you use — especially if the list is large.

The key problem

If your page setup:

Calls the database multiple times for the same list, or

Modifies the RG’s data source dynamically (triggering new queries),

…you’ll burn WUs unnecessarily, slow down page performance, and increase Bubble hosting costs.

How Turbo In-Memory Data Manager Solves This?

Instead of letting your RG directly query the database every time, the plugin changes the flow:

Normal Bubble flow (high WU cost):

UI Action → Database Query → Bubble Server → Browser

(UI Action) → Database Query → Bubble Server → Browser

(repeats every time you scroll, filter, or edit)

Plugin flow (optimized WU cost):

Page Load → Database Query (once) → Store in Plugin’s In-Memory State → Browser

UI Actions → Modify In-Memory Data (no DB call) → Instant Update

How it works step-by-step:

Load once

On page load, the plugin takes your database list (via “Source” property) and stores it in exposed states.

This initial fetch uses WUs only once.

Keep in-memory

The plugin holds the list inside the browser memory, not in Bubble’s server memory.

You can read from these states as much as you want — zero WU cost.

Modify without re-querying

Add, delete, or update rows in memory.

Bubble doesn’t hit the database again.

Save only when needed

When you’re ready to commit changes, you run a workflow to save everything in one go.

This means one write batch instead of many scattered writes.

See plugin page

Editor

Get yours now

If u guys have any suggestions, feel free to drop a comment .

[Jici]

What I’m reading here sound more like someone that doesn’t really understand correctly how WU work in Bubble. First… it’s called WorkLOAD and not work unit.

Two Filtering and sorting doesn’t cost more WU. In fact, filtering on server-side can save WU.

Scrolling and pagination can also save WU by not loading data that is not needed at first. While your plugin will load the entire data leading to cost more WU if the user doesn’t scroll or stop to scroll fast.

As for:

@SAIDER1

Dynamic updates — If your page setup re-triggers the search (e.g., when an input changes), Bubble starts over, fetching from the DB again.

This can be easily solve with native Bubble state function an Set state. No need for a plugin for that. And doing this, we can also do the filtering on this list on client-side instead of fetching data again. Again, no need for a plugin for that.

So maybe your plugin can, in some case, save WU… but you should demonstrate this clearly. But also what is different VS using a state (and we should pay for your plugin).

[SAIDER1]

You’re absolutely right that Bubble calls it Workload Units (WU) and that server-side filtering/sorting is often more efficient. And yes — in many cases, Bubble’s own custom states can be used to avoid repeated queries.

Where this plugin shines is in a specific set of scenarios where Bubble’s native tools either:

Don’t scale well in terms of workflow complexity, or

Make it hard to handle more advanced in-memory editing before saving.

For example:

Multi-field editing & tracking – If you have 5–10 fields in a RG and want to allow edits, deletes, additions, and track exactly what’s changed (IDs for modified/deleted rows), Bubble’s native states require a lot of manual setup. Here, the plugin does it automatically.

Batch updates – Instead of saving per-row or on every change (each triggering DB writes and workflows), the plugin keeps everything client-side until you explicitly save.

Preloading for instant UX – Yes, we fetch the full dataset once, but that’s intentional for use cases like spreadsheets, dashboards, or inventory systems where the user is likely to scroll/filter a lot. The speed gain from avoiding repeated fetches can outweigh the initial load.

Unified exposed states – All fields, indexes, and change-tracking lists are available instantly for workflows, without setting up dozens of separate custom states.

I agree this approach isn’t for every RG scenario — if you only need paginated read-only lists, Bubble’s built-in pagination is best.

But for interactive multi-field lists that will be heavily edited or filtered client-side, preloading into in-memory state can reduce both workflow complexity and total WU over the session.

[ihsanzainal84]

Unless you’ve discovered a way to mimic Bubble’s call to an app’s DB within a plugin, this plugin is extremely niche. A builder will still need to initiate a workflow to update records. There’s also the matter of loss of progress if a user is editing in bulk.

Not a diss on the effort put into your plugin cause I did try to build a similar plugin in the past. Eventually I realized the WU saved is so minimal versus a UX that forces a “Save” action on the user before updating a record.

If I as a builder have to go through additional effort to save WU dealing with bulk records, then Data Jedi by @boston85719 has more tangible WU savings. Since it forces working with raw JSON values and involves using cheap (WU) API calls. It would also be easier to implement a browser storage solution for session progress too, since I can key value the JSON to a record’s UID.

[SAIDER1]

Totally valid points — this plugin isn’t a drop-in replacement for Bubble’s DB or something that magically saves WU in every scenario.

It’s designed for a specific workflow pattern:

You need to fetch data once from the database at page load

Keep it fully editable in-memory with no additional DB calls while the user works

Track exactly what’s been changed, deleted, or added — all ready for one batch save

You’re right that builders will still need to run a workflow to push updates back to the DB. But the WU savings come from eliminating all the intermediate writes and repeated searches during the editing session.

For example:

Without plugin → Each field edit triggers a state update and possibly a DB update (depending on workflow setup)

With plugin → No DB writes until the user explicitly clicks save; all changes tracked automatically in exposed states

Regarding UX, this pattern is already common in spreadsheet-style apps, bulk inventory systems, order management tools, etc., where the “Save All” button is expected. It’s less about forcing a save and more about enabling safe, high-volume editing without performance dips or wasted WU on mid-edit updates.

Compared to JSON-based tools like Data Jedi, my plugin aims for a no-code friendly workflow. Builders can still access all fields via exposed states without needing to parse JSON or set up API calls — which can be a barrier for some users.

As for session progress, you’re right — browser storage could be added as a safeguard for long edits. That’s actually something I’ve been considering as an optional feature so the in-memory state can persist between reloads.

So yes, it’s niche — but for the right type of app, it drastically simplifies setup and keeps workload predictable.

[net-tt]

Data Jedi is pretty expensive ($150 one time).

Templates for Bubble

[ihsanzainal84]

That’s the unfortunate downside IMO too.

That said though, plugin developers have the right to charge what they feel is worth their effort. Still I disagree with a lot of prices for a lot of plugins because i can gauge how much effort they take to build. It’s especially abhorrent in the mobile native plugins marketplace since it’s monopolized by the few who are testing the native plugin builder.

[boston85719]

@ihsanzainal84

Data Jedi by @boston85719 has more tangible WU savings.

Thanks @net-tt for pointing out the cost. It is a bit of a different plugin as Data Jedi doesn’t do just one thing, and in fact, it works in a very, very different way than Turbo Data Faker.

I normally would not post about my plugin on the showcase page of another developers plugin, but since it has been used as a comparison and the post about the cost of my plugin marked as a solution to this thread, I figured, I need to publicly address the differences.

Firstly, plugins are Services. We need to pick our service providers carefully. I’ve been building on Bubble for 7.5 years and I created Data Jedi after I mastered Bubble itself. So, Data Jedi comes pre-built with all the little things that a Bubble developer would love from a plugin. A simple example there is event triggers when data changes, conditional actions using yes/no fields instead of checkboxes and a whole host of other goodies that come with extensive knowledge of how Bubble apps are built and how to expand the functionality of things with simple tweaks. Plus, the extended history of my career and continuous contributions to the community can help demonstrate a difference in service provider, which as in most services, may come with a higher price tag.

Additionally, Data Jedi is not a plugin that does just one thing, as in saves WUs on data fetch or client side manipulation. It is a beast, getting added to and updated by a professional developer who builds apps with it himself daily. It currently has 23 Elements, 17 Actions, and 4 API calls.

Not only does it have these, but these elements and actions allow users to communicate across the entire app, not just between pages/reusables that have the elements on them, which means, users can create a Global Data Center that controls all CRUD operations, as well as Local Storage, Structured Data, Data Export, Data Import, Image/File Upload. It has more than that as well, such as the compare two things, or compare two lists which allow users to create visual identification to which fields/elements have values changed, enables easy reversion to previous values, and makes bulk updates to tens of thousands of objects cost next to nothing and can be done very quickly client side, but also there are server side actions to compare lists of things too.

Fetch - Modify - Save 51,200 things for less than 45 WUs - No External DB

I just tested a larger set of data using my Plugin Data Jedi as I saw a couple of posts today about larger lists of data. One in particular was interesting to me. The question was about creative ways to reduce WUs for large lists of data like 100,000 things. I didn’t test with 100,000, I did test with 51,200 and was able to Fetch, then Modify and then Save all 51,200 things for less than 45 WUs in less than 5 minutes on the Client Device using a Mac Desktop from 2013. [Data Jedi]

I also just updated and need to provide more guidance to support for the approval of the Searchbox element. This element enables search function with matching against multiple fields at once, as well as against ALL 4 data types in Bubble (custom data types, option sets, api objects and plugin objects).

So, it is safe to say that although the two plugins may be capable of doing something similar (ie: reduce WUs), one can do that drastically by 95-99% on both data fetch and bulk create and modify, the other from what I can tell just ensures the user will download All data even if not needed for their session and in doing so, ensures the WU costs of a full fetch are incurred, regardless of whether the user needed to fetch all data or not.

With all of that said though, I think the month by month pricing comparison is better to help understand differences in cost ($15 compared to $5), and the focus on what the plugins really do to ‘save WUs’ and what other features/functions do they offer to help understand the differences in value, could help differentiate the two plugins from each other, because they really are nothing alike.

@net-tt if you’d like to take Data Jedi for a spin, let me know an app id in a PM and I’ll give you access.

[senecadatabase]

I suppose the amount the plugin developer charges depends on how much the plugin helps you earn or save.

If the plugin saves you $50 a month conservatively ($600 yearly, year after year), then $150 would be a great investment.

It’s like having an employee you pay $800 a week to do a task. If a machine comes along for $5000 that can do the same task, that would be an investment that would continue to pay for itself month after month.

I’m going to give the Data Jedi a trial and see how it goes.

From what I’ve read, it’s a no-brainer when it comes to running an app business. Not sure if my app is that data heavy yet, but hopefully (as we all hope), in time it will grow and the plugin will more than pay for itself many times over.

[net-tt]

Your plugin definitely does much more than the OP’s plugin. It is overkill to use your plugin for the OP’s plugin’s intended usage. But when the needs arise, I will definitely check out your plugin.

[senecadatabase]

Sounds like you have a plan.

I’ve always found it easier to build for big usage from the beginning than to try and rebuild later. It seems to save a lot of headaches.

I build with the thought of 10,000 daily users…it’s just a number I feel is fairly safe. Maybe it’s overkill for some apps, and maybe conservative for a lot of others.

Either way, good luck with your projects.

[SAIDER1]

Thanks for the detailed breakdown — I think it’s important that people see the differences so they can pick the right tool for their situation.

Data Jedi is clearly a broad, feature-rich toolkit — it covers a huge range of data operations, from global CRUD to structured data management and even server-side list comparisons. That’s awesome for complex apps or developers who need those advanced workflows and are comfortable managing that power.

Turbo In-Memory, on the other hand, is intentionally narrow and focused:

Fetch your data once into memory when the page loads

Make unlimited client-side edits without hitting the database again

Track which rows were added, deleted, or modified

Push all changes back in a single save action

It’s built for builders who don’t need a 20+ element toolkit, but do want a simple, drop-in way to prevent unnecessary WU consumption from repeated searches and mid-edit saves. In many spreadsheet-style, inventory, or bulk-edit scenarios, the “load once / save all” pattern fits perfectly.

It’s true that Turbo will fetch the full dataset upfront — and that’s intentional. It trades the initial cost for zero additional fetch costs during the edit session. In scenarios where the full list will be viewed or heavily edited, this approach is still very efficient, and the UX feels instant after the initial load.

I think both plugins have their place:

Data Jedi is a Swiss Army knife for data — broad scope, advanced optimization, many built-in utilities.

Turbo In-Memory is a laser-focused helper — minimal setup, quick to learn, purpose-built for a specific workflow pattern.

That way, builders can choose based on whether they want a specialized lightweight tool or a comprehensive data management suite.

[boston85719]

@net-tt

It is overkill to use your plugin for the OP’s plugin’s intended usage

I wouldn’t necessarily say it is overkill. When Bubble announced their WU pricing strategy, my first reaction was that data fetching would be prohibitively expensive, and requested a feature to allow us to elect which fields we want returned. That is because a large part of the cost of fetching is the number of characters of data returned. However, in practice, the real driver of why fetching data is so WU intensive, is the cost associated with each item returned.

When I set out to come up with a solution for my own apps as after 18 months, it became evident Bubble was not going to implement the features to help reduce the costs of fetching data, I had to tinker and play a lot with different concepts until landing on the one that works.

The best and truly only way to really reduce the cost of WUs using plugins with no 3rd party layers (ie: pretty much just Bubble), is to use a Hybrid Data Structure approach, in which you use API objects instead of custom data types. So what happens here, is if you compare legacy data structure in which only option sets and custom data types are utilized to a hybrid data structure, in which all four data types are utilized, the same apples for apples data fetch of a particular type of data and data set, using a hybrid data structure you could return, for example a list of 1,000 api objects with the same exact number of characters of data, as a custom data type fetch of 1,000 data entries, but the difference is that hybrid data structure approach is going to actually fetch just one single thing while custom data type fetch is going to return 1,000 items. So the WU cost savings is 999*0.015=15 WUs, while the per character cost is equal.

What I say this means is, the Data Jedi plugin is fit for the job and delivers the type of results desired, but by no means is the only way to achieve the results. Now, the whole hybrid data structure approach is really the key, it is not that Data Jedi makes it possible, anybody can implement the hybrid data structure approach without a plugin, since Bubble database by default allows us to store api objects as fields in custom data types. There are various free plugins that can be cobbled together to get the same type of functionality needed to create and modify api objects, but Data Jedi just makes it simple and a real ‘no code’ solution for those tasks.

@SAIDER1

Track which rows were added, deleted, or modified

Yes, I see how the plugin is doing that with it’s exposed states of lists of index numbers, referencing likely the index value of the JSON array the plugin creates. This doesn’t really make it that easy to work with though as the added, modified and to delete tracking is not tracking ‘objects/things’ it is just tracking a number value, so it is a bit more difficult to more feature rich value from it, such as knowing which field was modified, or what are the other field values of modified items etc.

The setup of the plugin element itself as well is a bit cumbersome and limited. If the user is needing to add source values for each field and a field type for each field and is limited to just 10 fields, it becomes less versatile and useful, especially in scenarios of viewing the full list of data in a dashboard as there are so many scenarios in which a data type will have more than just 10 fields.

You could alter the way the plugin operates to have a single field that is the type of data and another field that is the data source, making it simpler for users to setup. And have the plugin detect the fields, their types from the datasource, so that it is not limited to just 10 fields, makes it more versatile and easier to set up and enables the functionality to track the complete ‘object/thing’ in the exposed states rather than just an index value. If you made those changes it could definitely be minimal setup, quick to learn and built for reducing the number of data fetches needed per session.

Also, make sure the plugin works properly with Dates. In the demo the date field is just a number (your input) but the plugin shows as field type of date, so no matter which value I enter into the date input, the date value is Jan 1, 1970.

Also, you need to make it so that the Create portion part of the process is not going to ADD extra WU consumption. Currently you plugin requires the save process to have a very cumbersome setup, meaning the developer has to program, each ‘create thing’ which means, that it is not easy, nor performant and very very limited. How is a developer supposed to set it up so that when a user creates 1,000 items the save part actually works? Is that a requirement of having 1,000 create new thing actions all with conditionals?

What you are doing with that setup is adding a lot of extra WU consumption on the tail end of things. So yes, maybe they do save WUs from not saving between each edit, but at the end of the day, your plugin still incurs the same amount of WUs on the save portion because you have to run individual create new thing actions, or make changes or delete, and all need conditionals referencing a item number. And the plugin forces the entire data set to be loaded even if not needed. At this point I am failing to see where the WU savings are, or where the minimal setup part come into play.

What you could do is create an action that will run a bulk update api call so that all items are created in a single action, and that way it is not limited in anyway and delivers actual WU savings on the create side of things.

In the demo I see 13 actions, all with conditionals, to determine if there should be a delete or create, and there doesn’t seem to be anything that changes the icon from delete to save when I have an existing data entry that I modified, so it is hard to determine how you intend users to modify the existing data inside the database.

Below is an example of how Data Jedi can enable to bulk create, modify or delete in a single action series.

Just 3 actions, one for create, one for modify and one for delete. The modify and delete at this stage are still just one item at a time (will change in near future) but the create part is unlimited and that delivers considerable WU savings on that side of the equation as well.

If you were to update your plugin with my suggestions, I believe you would have a decent plugin that can deliver some WU savings in some situations and would provide for a minimal setup and quick learning (I say this because learning how to modify based on an index value is harder than modifying based on an item ID).