- 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
- 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
- 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
- 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