# How to structure a Bubble database for scalability

**URL:** <https://forum.nocodework.com/t/how-to-structure-a-bubble-database-for-scalability/94>\
**Category:** General\
**Tags:** bubble\
**Created:** [May 28, 2025, 10:30am UTC](https://forum.nocodework.com/t/how-to-structure-a-bubble-database-for-scalability/94 "2025-05-28T10:30:08Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![Sagar\_Patwal1](https://yyz2.discourse-cdn.com/flex032/user_avatar/forum.nocodework.com/sagar_patwal1/32/20_2.png) [@Sagar\_Patwal1](https://forum.nocodework.com/u/Sagar_Patwal1)\
**Post date:** [May 28, 2025, 10:30am UTC](https://forum.nocodework.com/t/how-to-structure-a-bubble-database-for-scalability/94/1 "2025-05-28T10:30:08Z")

</div>

1. Use Option Sets for Static Data

Option Sets are like constants—small sets of data that rarely or never change (e.g., roles, countries, order status).

Why it’s scalable: They load faster because they’re stored in the app, not in the database.

How to use:

Go to Data → Option Sets  
Create an option set like “User Role”  
Add options: “Admin”, “User”, “Manager”  
Use this instead of a custom data type for static labels

1. Link Data Types Instead of Storing Lists

Bad practice: Adding a list of Orders directly to the User object  
Better:Each Order has a field called Created By that links to the User

Why:

Bubble has trouble loading large lists stored inside a single field  
Queries are more flexible when data is normalized

1. Avoid Deep Nesting

Problem:Storing things like:

Company → Projects → Tasks → Subtasks (each as a list field)

Better Approach:

Each Task has a field Project  
Each Subtask has a field Task

Why:Easier to search and filter, less data overload  
4. Use Constraints, Not Filters

Bad:Doing a search and filtering in the front-end  
Good:Use constraints in the search itself

Do a search for Tasks where Project = Current Project (constraint)

Why: Constraints run on the server = faster  
Filters run in the browser = slower, especially with large data sets

1. Avoid Unnecessary Fields and Lists

Example: Don’t store a list of “Users who liked this post” if all you need is a count

Better: Have a separate data type called Like with fields:

User  
Post

Thanks  
Sagar Patwal