Skip to content
Kelly's Data Modeling Manual
Kelly's Data Modeling Manual
Common Data Modeling Scenarios
Core Concepts
Glossary
Share
Explore

icon picker
Data Types vs. Option Sets

About Data Types

A data type is where you store data that:
a user might be able to create, update, or delete (i.e., a project, a task, a company, a journal entry...)
might have some sensitive information attached to it (i.e., an API key, or a bank account number)
might be updated occasionally or even frequently

About Option Sets

Your option sets are basically a separate little database that behaves a little differently than your data types. Option sets contain data that...
don’t typically change all that much - sometimes never (i.e., days of the week, project statuses, app permissions)
you as the app developer create and maintain (users can never create or modify options)
do not contain sensitive data (see below)
Option sets are really handy because you don’t have to “search” your database for the option you need. You can use the “get an option” expression and then just find the option you want.
Some downsides to Option Sets:
If you make changes to them, you have to deploy your app for those changes to take effect for users.
The UI of the Option Sets panel in Bubble is terrible (this will hopefully change, but no one is holding their breath).
You cannot upload a CSV to an option set, or duplicate options or sets.

When to use which one

Here’s how I go about this: When I’m looking at a bit of data that needs to be saved in my app, I ask myself...
Question
If yes...
If no...
Should a user ever (ever ever ever, even once) be able to create, edit or delete one of these things?
Make it a data type.
(move on to the next question...)
Will I ever be saving any sensitive data related to this thing?
Make it a data type.
(move on to the next question...)
Once my app is up and running, will this information need to be changed or updated more than once every couple of weeks?
Probably make it a data type, but keep going...
(move on to the next question...)
Will the options literally never change? (Like the days of the week or months of the year)
Make it an option set.
(move on to the next question...)
Will I have more than 20 or 30 records?
Probably make it a data type.
(move on to the next question...)
Will new records need to be added at some regular interval forever? (example: an event management app where there’s a new event every 3 months, there could in theory be endless records over type)
Make it a data type.
(move on to the next question...)
Do I want to upload this data from a CSV, or import from an API?
Make it a data type.

There are no rows in this table
⁠
By the time you get to the end of these questions, you’ll probably know what to do.

Some tricky ones

Tags and Categories - I walk through them here:
Tags & Categories
⁠
States or Countries - These rarely change, so an option set makes sense, but there are a lot of them, which you have to enter manually. You could much more easily run a quick API call to populate a data type with robust state/country data instead.

Security Considerations

Your data types live on Bubble’s server, and are only downloaded to your user’s web browser if you create a search for that data and if the privacy rules you’ve set up allow the retrieval of that data. Option Sets, however, download completely to your user’s web browser every time they load a page. Literally every letter of every option of every option set is delivered to your users, constantly. For that reason, you should never have anything that’s remotely sensitive saved in an option set. That stuff goes in a Data Type.
Want to print your doc?
This is not the way.
Try clicking the ⋯ next to your doc name or using a keyboard shortcut (
CtrlP
) instead.