Data types and fields

This section covers what data types are and how you can set up custom types of data with fields holding different kinds of information

We also have multiple guides on how to set up your database structure based on what kind of app you are building. You can take a look at these in our article series on Database structure by app type.

Article series: Database structure by app type

You may also be interested in our introductory guide to planning your database structure:

Article: Database structure

Data types

The database consists of different data types that you as the developer plan and set up. Data types are like containers that hold specific types of information and each data type is made up of fields where that information is stored.

For example, in a sports league management system, one data type might be used to hold information about teams, such as their name, coach, and roster of players. Another data type could be used to hold information about games, such as the date, location, and final score.

With our visual editor, you have complete freedom to structure, manage, and connect data types as you want.

Let's first have a look at how you create new data types:

Creating data types

You can create as many data types as you need. To create one, follow the steps below:

  1. First, navigate to the Data tab in the Bubble editor

  2. Then, go to Data types

  3. In the field labelled New type, provide a name. Don't worry, you can this at any later time.

  4. Click the Create button

The new data type will be added to the Custom data types list.

Naming Data Types

Bubble lets you name your Data Types as you please, even using characters such as space. While you are free to name them as you please, it can be useful to follow a few guidelines:

  • Use unique names: While Bubble does support duplicate names, giving your data types unique names makes it easier to identify the correct one. Keep in mind that this can affect as well, as Option sets and data types will often show up in the same lists.

  • Use singular names: Bubble automatically pluralizes names. For example, if you name your data type Event, Bubble will automatically refer to it as Events whenever it's appropriate

Video lessons

Fields

Each data type consist of fields that hold different kinds of information. These fields are formatted in specific ways and can only hold the type of information that they are set up to contain.

To illustrate, think of a phone book: a Contact has different fields for name, date of birth and email address and the format of these fields remains constant: name and email address will always contain text and date of birth will always contain a date.

The field is where the information saved to a data type is actually stored.

Bubble has the following built-in field types:

  • text A string a text that can contain any kind of character

  • number A numerical value, which can be a whole number or a decimal. Bubble formats numbers in US standard format, meaning that the period (.) is used to separate the integer part from the fractional part of a number (e.g., 1234.56).

  • numeric range A range consisting of a low and a high value, such as 5-10

  • date Contains a date and time

  • date range A range of dates, such as 1/1/1970 - 1/15/1970

  • date interval A Date interval quantifies the difference between two dates. It/s the number of days/hours/minutes/etc between them

  • yes / no A value that can be true or false (sometimes called a boolean)

  • file The URL of a file

  • image The URL of an image file

  • geographic address A Google Maps formatted address

  • Data type Any data type that you can set up can also be a field type

This is where the flexibility of Bubble's database becomes apparent: by creating custom data types and populating those types with custom fields, we can set up a structure for almost any thinkable scenario.

The last item on the list above is particularly significant. That's because every data type we create can be used to format a field in a different data type, which is how we interconnect them.

Storing a list of values

Each field can also be set up to store a list of values. For example, if you want to store more than one text value you can check the box labelled This field is a list (multiple entries). This lets you add new values that make up a list, such as Red, Blue, Green, Yellow.

Checking the option above lets you store a list of values instead of a single value.

Any type of field can contain lists, including custom data types. This way you can reference multiple things, such as the tags connected to a blog post or the products in a cart.

Video lessons

Built-in fields

In addition to the fields that you choose to add to a data type, Bubble will also set up the fields below:

Unique ID

The Unique ID is a 32-character string that identifies a specific in your database. The Unique ID (sometimes shortened to UID) is generated automatically when the thing is created and cannot be edited.

A Unique ID looks like the example below:

1651238619517x600101118159717500

Date created and Date modified

These two fields are also automatically populated by Bubble and are stored in the date format. The Date created field never changes, and the Date modified field automatically updates any time any changes are made to the Thing.

Slug

The slug field lets you set up a user-friendly and search engine optimized URL for the thing. When you , you can instruct Bubble to use this string of text as the last part of the page's URL, to give each thing a unique URL.

For example, if the name of a Product is "A Beginner's Guide to Bubble," the corresponding slug might be "a-beginners-guide-to-bubble". The slug is then appended to the page URL such as:

https://www.myapp.com/products/la-beginners-guide-to-bubble

This lets you set up user-friendly and search engine optimized URLs for different data types such as articles, blog posts, products, and other types of content.

Changing the slug on a thing cannot be done with the action, but needs to be done with the action.

Custom field types

Any data type that you create can also be used as a field type. For example, say you have a data type called Cart, and to this cart you should be able to add Products. You can set up a field on the Cart data type, check This field is a list and choose the Product data type as Field type:

For instance, we can use a data type for a shopping cart to connect it to a data type for a user. By doing that, we can determine who the owner of that particular cart is.

Video lessons

Creating fields

After you have created your data type, you can set up the fields you need:

Click the image to see a bigger version
  1. First, select the data type on which you want to create a new field (Cart)

  2. Click the Create a new field button at the bottom of the existing fields

  3. Give the field a fitting name

  4. Choose the type of data you want to store in that field from the list above or from your existing data types. In this example we have selected User since we want the owner of the Cart to be a registered user

  5. Pick whether the field should contain a list of the selected data or a single item. In this case we want each cart to just have one owner, so we don't check the box.

Let's look at some examples of how varying app types may require different data types:

Examples

Data types

We'll go over three different examples to see how you can set up data types that cater to different applications. Note that the examples aren't intended to be a blueprint or the best practice for these categories. Instead, they serve to demonstrate the versatility of data types in various scenarios.

Example 1: eCommerce store

In an eCommerce store, we might need three data types to handle basic functionality. We want Users to be able to add Products to a Cart:

Product

Cart

User (built in)

Example 2: Sports league management app

Managing a sports league could require a bit more complicated setup: a league consists of different Clubs, that each have a few Teams with Players. The players play Games. The Player data type is actually the built-in User data type. Since Bubble already provides this data type that allows users to log in and use the app, it makes sense to use it. Keep in mind that the User data type cannot be renamed. Therefore, we're simply clarifying that it's referred to as a Player in this particular context.

League

Club

Team

Game

Player (user - built in)

Example 3: Blog

A blog can have a very simple setup consisting of blog posts, tags that let you search for posts of a specific type and authors. Again, the Author type is the User type but to better convey its intended purpose, it's referred to as "Author"

Blog post

Tags

Author (user - built in)

Adding the fields

Example 1: eCommerce store

Product

Name (text) Description (text) Image (image) Price (number)

Cart

Owner (user) Products (list of Products)

User (built in)

Name

Example 2: Sports league management app

In our Sports league management app we can really see how data types are referenced downward in the hierarchy: a Player is a part of a Team, which is a part of a Club, which is a part of a League.

League

Name (text)

Club

Name (text) League (League)

Team

Name (text) Club (Club)

Player (user - built in)

Name Email (built-in) Team (Team)

Example 3: Blog

On our blog website we can return to a simpler structure. We have the blog posts, on which we need to store 1) the header and post content, both texts, 2) The User who wrote it (the author) and the list of Tags (such as Politics and Tech).

Blog post

Header (text) Post (text) Author (User) Tags (list of Tags)

Tag

Name

Author (user - built in)

Name Email (built-in)

As we've explored, setting up custom data types and fields lets you adapt your database to suit your project. In simple terms, data types are the containers that define the type of data you want to manage, while fields contain the various types of information stored within that data type.

If we were working on a phone book, the data type would be Contact and the fields would Name, Email address and Phone number.

Important information when deleting fields

When you delete a field from a data type in your database, the data stored in that field is not automatically removed. While the field no longer appears in the editor and cannot be used in workflows or design elements, the underlying data remains in your database and may still be retrievable through API calls or visible in network responses.

This behavior helps preserve the functionality of any privacy rules that may reference the deleted field, even if those references are no longer visible in the editor. However, there are important implications to keep in mind:

Key points to understand:

  • Privacy rules still apply: If a privacy rule previously referenced the field, it will still be enforced at runtime, even though it no longer appears in the editor. Because these rules are no longer visible or editable once the field is deleted, we strongly recommend either clearing the field’s data beforehand or carefully reviewing your privacy rules to ensure the data remains protected before deletion.

  • The data is not erased: Deleting a field only removes it from the editor. The values associated with that field still exist in the database.

  • The field can still be accessed via API: API responses (such as through the Data API) may still return the field's values.

  • No WU charge: Bubble does not charge workload units (WU) for data retrieved from deleted fields.

  • Risk of unprotected data: If no privacy rule currently protects the field, the data could become accessible to unauthorized users through API responses or network activity.

  • App optimization: The feature does not remove this data.

Best practice:

Before deleting a field, we recommend the following:

  1. Clear any sensitive data from the field before deletion, such as through a backend workflow or manual database edit.

  2. Review privacy rules to understand whether the field is protected and whether protections need to be adjusted elsewhere.

  3. Test your app and API responses to ensure no unintended data exposure occurs.

This behavior is designed to avoid silently breaking privacy rules when fields are removed, but it also means that extra care should be taken when deleting fields that store sensitive information.

Other ways to learn

Video lessons
Articles
  • Planning your database structure This article takes an introductory look at how to plan the database structure for your app. Article: Planning your database structure

  • Maintaining your database Keeping your database clean and up-to-date helps your app run efficiently and makes it easier for you as a developer to stay on top of the data. Check out our article series below for different ways of maintaining your database. Article series: Maintaining your database

Last updated

Was this helpful?

Revision created

GITBOOK-1046: Minor typos