Skip to main content
Back to path

Welcome to a Grasp lesson

Create a free account to keep studying and create your own study path.

Lesson 6

Defining Custom Data Types

Recommended resources

Welcome to Module 2! In the previous module, we focused on the building blocks of the user interface and immediate interactivity—adding elements, creating workflows, and managing temporary data with custom states and conditionals. You've essentially built the "face" and "reflexes" of your app. Now, we're going to build its "brain" and long-term memory: the database.

This lesson marks our first step into the Data tab in Bubble. Here, we'll lay the architectural foundation for your entire multitool platform. The goal for today is to create your own custom data types and define what information they will hold. Specifically, we'll be creating the Tool and Category data types that are central to your project. This process is conceptually similar to how you might have used Advanced Custom Fields (ACF) in WordPress to define custom post types, but you'll find Bubble's approach is more visual and integrated into the core of the platform.

From Spreadsheets to a Relational Database

Before we dive into Bubble, it's helpful to understand the core concept. Many people are familiar with spreadsheets like Excel or Google Sheets. You can think of a Bubble database as a collection of very powerful, interconnected spreadsheets. Each "sheet" is called a Data Type, and it's designed to hold one specific kind of thing, like a User, a Tool, or a Product. Each "column" in that sheet is a Field, which stores a piece of information about that thing, like a Name, a Description, or a Price.

Where a Bubble database really shines over a simple spreadsheet is in its ability to create relationships between these data types. The following article from Bubble's blog gives a great high-level overview of this concept.

How to Design a Relational Database

This article explains the core idea behind relational databases and why they are more powerful than simple spreadsheets for building applications.

Focus on the section How relational databases work. It clearly contrasts the "one-to-one" limitations of a spreadsheet with the flexible "one-to-many" or "many-to-many" relationships you can build in a proper database.

Planning Your App's Data Structure

One of the most critical steps in building a scalable application—a key goal for your project—is planning your database structure before you start creating it. Think about all the pieces of information your app will need to store. For your multitool platform, let's outline the two most important data types: Tool and Category.

  • Tool: This will represent a single utility on your platform. What do we need to know about each tool?

    • Name: The title of the tool (e.g., "Word Counter"). This will be a text field.
    • Description: A brief explanation of what the tool does. Also a text field.
    • Icon: A visual representation for the tool. This will be an image field.
    • Category: Which category the tool belongs to (e.g., "Text Tools," "Converters"). This will be a link to our Category data type.

  • Category: This will represent a grouping of similar tools.

    • Name: The title of the category (e.g., "Text Tools"). This will be a text field.
    • Icon: A visual for the category, if desired. An image field.

This simple outline acts as our blueprint. Having this clarity makes the next step of actually building the database much more straightforward.

Creating Data Types and Fields in Bubble

Now for the hands-on part. We'll translate our blueprint into a real database structure in the Bubble editor. You'll navigate to the Data tab and use the "New type" input to create your data types.

The 'Data types' section in the Data tab is where you define the core tables of your database. You'll type the name of your new data type, such as 'Tool', and click 'Create'.

Once a data type is created, you can define its fields. Bubble offers several built-in field types, such as text, number, yes/no (a boolean), date, and image. Most importantly, any custom data type you create can also be used as a field type, which is how you create relationships.

The official Bubble documentation provides a clear, step-by-step guide to this process.

Data types and fields

This document covers the fundamentals of creating and defining data types and fields in Bubble, with helpful screenshots and examples.

First, read the brief introductions under Data types and Fields to solidify the core concepts. Review the list of field types. Read the section on how to create a data type. Then, follow the steps for creating fields. Pay close attention to how the example selects User as the field type to link a Cart to its owner. This is the same principle we'll use to link a Tool to a Category. Finally, skim the Examples section to see how these concepts are applied to different app types like an e-commerce store or a blog.

To put this into practice, follow the steps from the documentation to create your Tool and Category data types with the fields we planned earlier.

  1. Create the Category data type with a Name (text) field.
  2. Create the Tool data type.
  3. On the Tool data type, create the fields: Name (text), Description (text), and Icon (image).
  4. Then, create one more field on Tool named Category. For its "Field type", don't select text; instead, scroll down and select your Category data type. This creates the crucial link between the two.
When creating a field, you give it a name and select its 'Field type'. Here, a field named 'Owner' is being linked to the built-in 'User' data type, establishing a relationship.

The following video provides a great visual walkthrough of this exact process of creating and linking two data types.

Mastering the Bubble Database: A Beginner's Guide | Bubble.io Tutorials

This PlanetNoCode tutorial provides a concise demonstration of creating and linking data types, and introduces the useful concept of Primary Fields.

Watch from this section to see a new data type (Book) and its first field (title) being created. Then, from this part, observe how a second data type (Author) is created and then used as the field type within the Book data type. This directly mirrors what you just did with Tool and Category. Finally, watch the explanation of Primary Fields. This is a helpful tip: setting a primary field (like the Name on your Category type) tells Bubble to show you that human-readable name in the editor instead of a long, random Unique ID.

Database Design for Scalability

How you structure these relationships has a major impact on your app's performance and scalability. A common question is: "Should a Category have a list of its Tools?" or "Should each Tool just know its Category?"

For scalability, the best practice is almost always for the "child" object to link back to its "parent." In our case, the Tool is a child of Category. Therefore, having a Category field on the Tool data type is the correct approach.

Why? If you were to put a List of Tools field on the Category data type, Bubble would have to load that entire list of tool IDs every single time you access any information about that category, even if you just wanted its name. For a category with thousands of tools, this would slow your app down. The other way is far more efficient: to find all tools in a category, you simply tell Bubble, "Do a search for Tools where the Category field equals this specific category."

This video explains this crucial concept in detail, using an Airbnb clone as an example. The principles are universal and directly apply to your project.

How to structure your Bubble.io database

This video from nocodelife goes beyond the "how" and explains the "why" behind good database design, focusing on performance and scalability.

First, watch the section on creating relationships. It explains why linking a Property back to its User (owner) is much more efficient than linking via a simple text field. Next, pay close attention to the discussion about lists on data types. This covers the performance trade-offs of storing a list of items on a parent object and reinforces why searching is often the better, more scalable method. Finally, the segment on when to create a new data type (using 'Reviews' as an example) is excellent. It shows that if you need to store multiple pieces of information about something (like a review's text, star rating, and author), it deserves its own data type.

Conclusion

In this lesson, we moved from the front-end to the back-end, establishing the data architecture for your multitool platform. This is a foundational skill that separates simple web pages from powerful web applications.

Here are your key takeaways:

  • Data types are the primary tables of your database (like Tool), while fields are the specific pieces of information stored within them (like Name and Description).
  • Planning your database structure on paper first is a crucial step for building a logical and scalable app.
  • You can create relationships between data types by using one custom data type as the "Field type" for a field in another.
  • For performance and scalability, it's best practice for a "child" object to link to its "parent" (e.g., Tool links to Category), rather than storing a large list on the parent.

You've now successfully defined what a "Tool" and a "Category" are in your app's database. In our next lesson, we will look at a more specialized and efficient way to handle fixed lists like your categories. While using a data type for categories works, Bubble provides a feature called Option Sets that is often better suited for this purpose, and we'll explore why.