The database

This section covers different aspects of how the Bubble database works

The database is the cornerstone of most apps. It handles all the dynamic data, meaning the data that you and your users can create, change, view, and delete as often as needed. That's different from the fixed text and images you place in the editor, which stay the same for everyone. Every signup, every saved post, every user profile in your app lives in the database.

Your app's user interface is all your users ever see, while the database works quietly underneath, doing its job out of sight.

The database works in tandem with your app's design so your users can work with complex data efficiently, without being burdened by the mechanics of how it happens under the hood. Most of your users don't know how it works, and don't even know it's there. They just know that the information they stored in your app yesterday is still there today for them to interact with.

What is a database?

When you hear the term database, you might imagine vast servers, intricate code, and complex structures. But with Bubble, the database is designed to be easy to use and understand.

At its core, a database is a structured collection of data. Think of it as a digital library, where instead of books, you have data entries, and instead of shelves, you have tables, or in Bubble's terminology, data types. Each data type can have several fields that store specific kinds of information. For instance, a data type User might have fields such as Name, Address, and Date of birth.

Database example

The table below shows what a small database might look like in practice: two data types, User and Blog post, each with their built-in fields and a few custom ones added on top.

Data type	Field	Description
User (built-in)	Email (built-in)	Built-in. Email is used for user authentication (signing up and logging in).
	Created date (built-in)	Built-in. The date/time when the thing was first created.
	Modified date (built-in)	Built-in. The date/time when the thing was last modified.
	Unique ID (built-in)	Bubble generates a unique ID for every thing in your database.
	Slug (built-in)	Built-in, but not automatically generated. The slug field stores a URL-friendly identifier for a record, like a username in a profile link, and you have to set its value yourself.
	First name (custom)	A custom field, usually set to type text.
	Last name (custom)	Same as above.
	Profile picture (custom)	A custom field of type image.
Blog post (custom)	Created date (built-in)	Built-in. The date/time when the thing was first created.
	Modified date (built-in)	Built-in. The date/time when the thing was last modified.
	Unique ID (built-in)	Bubble generates a unique ID for every thing in your database.
	Slug (built-in)	Built-in, but not automatically generated. The slug field stores a URL-friendly identifier for a record, like a username in a profile link, and you have to set its value yourself.
	Post title (custom)	A custom field of type text, holding the title of the blog post.
	Post content (custom)	A custom field of type text, holding the content of the blog post.
	Author (custom)	A custom field of type user, referencing the user who wrote the blog post.

New to terms like data type, field, and thing? There's a glossary at the end of this article you can refer back to.

Within Bubble, this database is visual and intuitive. You'll find it in the Data tab, where, instead of writing SQL queries or scripts to manage your data, you work with a clean, graphical interface. You can create new data types, add fields, or adjust the relationships between different data types with a few clicks. And while Bubble takes care of the heavy lifting in the background, keeping your data secure and retrievable, you can focus on designing the logic and flow of your app.

Every data type also comes with a handful of built-in fields that Bubble fills in automatically: a Creation date, a Modified date, the Created by user, and a unique ID. That unique ID identifies one specific record, so even if two users happen to share a name, your app can always tell their entries apart.

For those familiar with traditional databases, Bubble's approach simplifies many of the complexities involved. There's no need to stress about database schemas, SQL syntax, or indexing. Bubble handles these technical aspects, so you can focus on the logic and design of your app.

The database comes with its own set of commands to create, manipulate, and delete data.

How the Bubble database is different from SQL

Technically, Bubble uses the same technology as the majority of other web servers: SQL, and specifically PostgreSQL. So the underlying technology is familiar, it's just the way you work with it that's different, and that can be a bit confusing if you come from a traditional database background.

If you've worked with SQL before, the biggest shift is that you never write queries. Instead of commands like SELECT, WHERE, and JOIN, you build searches visually through dynamic expressions. And instead of manually defining tables, columns, and relationships in script, you set all of that up in the editor with a few clicks.

The other major difference is that Bubble automates the use of primary and foreign keys. When you create a relationship between two data types (tables), Bubble uses a custom data type field to represent a reference to another record in a different table.

For example, say we have a User data type and a Post data type, and we want each post to be associated with a user. In Bubble, we'd create a field in the Post type with the data type User, which represents a reference to a user record in the User type.

While Bubble doesn't expose foreign keys to developers, database relationships still technically rely on them. The unique ID field serves as the primary key for a record and is used to retrieve data, but this part of the process is hidden to make database setup and management easier for users without a database background. You may have use for the foreign key in some select scenarios, but you generally don't need to reference it in Bubble the way you might in other environments.

For a fuller comparison, including how relationships map between the two, see the article below.

Article: Transitioning to Bubble from SQL

The quick tip video below shows how this works visually.

Video lesson: How to add a data type as a custom field

Communicating with the database

When you and your users interact with your Bubble app, two computers are involved:

• The device the user is accessing the app from (such as a laptop or cell phone)

• Bubble's server (located in a server park)

Whenever an action involves the database, such as reading, writing, or deleting data, that command is sent from the user's device to the server, where the job is completed and a confirmation, along with any requested information, is sent back to the device.

Working with data in your app is an ongoing stream of communication between the user's device and the Bubble server. This doesn't just happen on page load, but continually, as the user provides your app with actions and input. Even for a single user, small packets of data can travel back and forth several times per second.

As the developer, you can set up your app to send all sorts of commands to the server:

• Create things

• Make changes to and delete things

• Search for things and return the result as a list

• Find one specific thing and return its content

Any data sent between the user's device and the server is encrypted at all times, so it stays private. Say a user provides input about themselves, such as their name and date of birth. When that data is sent to the Bubble server, it's encrypted and can't be read by anyone else. It's also encrypted while stored on the server itself.

What is database encryption?

Encryption is a method used to protect information by converting it into an unreadable format. This means that even if unauthorized individuals or systems manage to access the database, they won't be able to make sense of the actual data unless they have the right decryption key or method.

Imagine your database as a diary. Instead of writing your secrets in plain English, you decide to use a special code only you understand. If someone were to find and read your diary, they wouldn't understand its contents without knowing how to decode it. Database encryption works on a similar principle, but with algorithms and cryptographic keys.

Bubble automatically keeps the database encrypted at all times.

Encryption at rest and in transit

The data in and sent from the database can be in two states:

• Rest means the data is stored on the server's hard drive. In this state, the data is encrypted using the industry-standard AES-256 encryption.

• Transit means the data is moving from the server to the user's device through the cables and networks that make up the internet. In this state, the data is encrypted with the TLS protocol, which ensures three important things:

  • The data is encrypted, rendering it unreadable if it's intercepted by unauthorized parties.

  • The source of the data, the Bubble server, is authenticated, which confirms the data came from a verified source and not an imposter.

  • The data's integrity is maintained throughout its transmission, so it isn't tampered with or altered along the way.

Privacy rules

Privacy rules govern which users can access which data. They're the most important part of your database's security, and the main thing standing between your users' private data and the rest of the world.

Without privacy rules, the data your app sends to a user's device can be accessed in full, even the parts your design doesn't display on screen. A privacy rule works at the database level instead, deciding what data ever leaves the server for a given user in the first place. That's what makes it different from simply hiding an element or filtering a search: those control what a user sees, while privacy rules control what a user can actually reach.

Any app that holds personal, sensitive, or otherwise private data relies on privacy rules to keep it protected.

We strongly recommend setting up privacy rules for any app that holds private or sensitive data before it goes live.

Article: Protecting data with privacy rules

Data types and fields

You now know the basic shape of a Bubble database: data types that hold fields, and fields that hold values. The next article puts that into practice, walking through how to create your own data types and fields from scratch.

Article: Data types and fields

Bubble database terminology

Term	Description
Constraint	A filter applied to a search to narrow down the results. For example, retrieving all products with a price less than $50, or blog posts that are marked as published.
Data source	Defines where the data in an expression or element comes from. This is often a specific search (Do a search for) or a direct reference to a type of data in the database (such as Parent group's thing).
Data type	Represents a category of data (e.g., User, Product, Order). Similar to a table in traditional databases.
Do a search for	The data source that retrieves data from the database based on certain constraints.
Field	An attribute or property within a data type (e.g., Email, Name, Price). Similar to a column in a table.
List	A collection of things. For instance, a user might have a list of favorite products. A field can be set up to store one thing or a list of things.
Privacy rule	Criteria that determine how data can be searched for, modified, or viewed based on user roles or other conditions.
Thing	An individual record or entry in the database.
Unique ID	A unique identifier automatically assigned to every thing in the database. Bubble uses it to reference and retrieve that specific record.

Additional resources

Technical information about the Bubble database

Server

The Bubble database is hosted on Amazon's Relational Database Service (RDS), which is part of Amazon Web Services. The database is encrypted using the industry-standard AES-256 encryption.

Database technology

Bubble uses PostgreSQL, an open-source database management system. In other words, we haven't invented a new kind of database system. We use one that's been in development for decades and is thoroughly tested and audited for stability and security.

This is one of the most widely used systems on the internet, and since it's based on the SQL standard (a very common database format), Bubble can communicate with other databases without worrying about compatibility.

How the Bubble database is different from traditional databases

Technically, Bubble uses the same technology as the majority of other web servers: SQL, and specifically PostgreSQL.

Still, the way the database is visualized in the Bubble editor can be a bit confusing if you come from a traditional database background.

The major difference is that Bubble automates the use of primary and foreign keys. When you create a relationship between two data types (tables), Bubble uses a custom data type field to represent a reference to another record in a different table.

For example, say we have a User data type and a Post data type, and we want each post to be associated with a user. In Bubble, we'd create a field in the Post type with the data type User, which represents a reference to a user record in the User type.

While Bubble doesn't expose the use of foreign keys to developers, database relationships still technically rely on them. The unique ID field serves as the primary key for a record and is used to retrieve data, but this part of the process is hidden to make database setup and management easier for users without a database background.

While you may have use for the foreign key in some select scenarios, you generally don't need to reference it in Bubble the way you might in other environments.

The quick tip video below shows how this works visually.

Video lesson: How to add a data type as a custom field

Other ways to learn

Video lessons

• The data tab

• Creating the data structure

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 to stay on top of the data. Check out the article series below for different ways of maintaining your database. Article series: Maintaining your database