Data types and fields

Every database in Bubble is built from two basic building blocks: data types and fields. A data type defines what kind of thing you're storing, like a user, a product, or a blog post. A field defines a specific piece of information that thing holds, like a name, a price, or a publish date. This article covers how to create and work with both.

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

If you were building a phone book, the data type would be Contact, and its fields would be Name, Email address, and Phone number. In a sports league management app, one data type might hold information about teams, such as their name, coach, and roster of players, while another data type holds information about games, such as the date, location, and final score.

With Bubble's visual editor, you have complete freedom to structure, manage, and connect data types however your app needs.

You can create up to 1,000 custom data types.

Navigate to the Data tab in the Bubble editor.

Go to the Data types section.

In the field labeled New type, enter a name. You can change this later at any time.

Click Create. Your new data type appears in the Custom data types list.

Bubble lets you name your data types however you like, even using spaces. That said, a couple of guidelines help keep things manageable:

Each data type consists of fields that hold different kinds of information. A field is formatted in a specific way and can only hold the type of information it's set up to contain. In a phone book, for example, a Contact has fields for name, date of birth, and email address, and those formats stay constant: name and email address always contain text, and date of birth always contains a date. The field is where that information is actually stored.

Bubble has the following built-in field types:

The last row in the table above is particularly significant: every data type you create can be used to format a field on a different data type, which is how you connect them to each other. This is where the flexibility of Bubble's database becomes apparent. By creating custom data types and populating them with custom fields, you can structure your database for almost any scenario.

For example, say you have a data type called Blog post, and you want each post to have an Author. You'd set up a field called Author on the Blog post data type and set its type to User, directly connecting a user to the blog post.

The same approach works for connecting other data types. For instance, you could create a field called Products on a Cart data type, check This field is a list, and choose Product as the field type, letting a cart hold multiple products.

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

Any field type can hold a list, including custom data types. This lets you reference multiple things at once, such as the tags connected to a blog post or the products in a cart.

In addition to the fields you choose to add, Bubble automatically sets up the following fields on every data type:

The Unique ID is a 32-character alphanumeric string that identifies one specific thing in your database. It's generated automatically when the thing is created, and it can't be edited. A unique ID (sometimes shortened to UID) looks like this: 1651238619517x600101118159717500.

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

You cannot make changes to any of these fields, as they are the 'source of truth' for when a record was created and last modified.

The Slug field lets you set up a user-friendly, search-engine-optimized URL for a thing. When you load data onto a page, you can tell Bubble to use this text as the last part of the page's URL, giving each thing a unique URL.

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

This lets you set up friendly, search-engine-optimized URLs for content like articles, blog posts, and products.

You can't change a thing's slug with the Make changes to a thing action. Use the Set a thing's slug action instead.

Once you've created a data type, you can set up the fields it needs.

Select the data type you want to add a field to (in this example, Blog post).

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

Give the field a fitting name, such as Author.

Choose the type of data you want to store, either from the built-in types above or from your existing data types. In this example, we selected User, since we want the author of the post to be a registered user.

Decide whether the field should hold a single item or a list. Here, each post should have just one author, so we leave the list box unchecked.

The examples below show how data types and fields might be set up for a few different kinds of apps. They're not meant as a blueprint or best practice for these categories, just a demonstration of how versatile data types can be.

An e-commerce store might need three data types to handle basic functionality: Users should be able to add Products to a Cart.

Managing a sports league takes a slightly more complex setup: a league consists of different Clubs, each with a few Teams made up of Players, and the players play Games.

The Player data type is actually the built-in User data type. Since Bubble already provides this data type to let users log in and use the app, it makes sense to reuse it. The User data type can't be renamed, so we're simply clarifying that it's referred to as Player in this context.

A blog can have a simple setup: blog posts, tags that let you search for posts of a specific type, and authors. Again, the Author type is really the User type, just labeled to better convey its purpose here.

This example shows how data types can reference each other down a hierarchy: a player belongs to a team, which belongs to a club, which belongs to a league.

For the blog, we need blog posts that store a header and post content (both text), the user who wrote it (the author), and a list of tags (such as Politics and Tech).