This section covers different aspects of how the Bubble database works
Last updated
#567: Moved Plugin API from Alpha to release
Change request updated
The database is the cornerstone of most applications. It handles all the dynamic data, meaning data that you and your users can create, change, view and delete as frequently as needed.
The database works in tandem with your app's design to give your users the combination of being able to work with complex data efficiently, without being burdened by the mechanics of how it actually happens under the hood. Most of your users don't know how it works and indeed don't even know that it's there – they just know that the information they stored in your app yesterday is still there today for them to interact with.
The database is of course where you store data, but it comes with its own set of commands to create, manipulate and delete that data.
Communicating with the database
When you and your users interact with your Bubble app, two computers are involved:
The device that 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 is needed that 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 and any requested information is sent back to the device.
As such, 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 be sent back and forth several times per second.
As the developer of the app, you can set it up to send all sorts of different 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, ensuring that it stays private. Let's say a user provides input about himself such as name and date of birth: when that data is being sent to the Bubble server, it's encrypted and can't be read by anyone else. It's also encrypted during storage on the server itself.
You can read more about the encryption in the infobox below.
Encryption during rest and transit
The data in and sent from the database can be in two states:
Rest means when the data is stored on the server's hard drive. In this state the data is encrypted using the industry standard .
Transit means when the data is moving from the server to the user's device through the interoptic cables that make up the internet. During this state the data is encrypted with the , which ensures three important points:
The data has been encrypted, rendering it unreadable in case of interception by unauthorized parties.
The source of the data, i.e. the Bubble server, has been authenticated, which guarantees that the data originated from a verified source and not an imposter.
The data's integrity has been maintained throughout its transmission, ensuring that it has not been tampered with or altered in any way during transit
Privacy Rules
Privacy Rules are rules that govern what users can access what data. It's the most important part of your databases security, and we strongly recommend that all apps that host any kind of private or sensitive data set up Privacy Rules to protect it.
The Bubble database is hosted on Amazon’s Relational Database Service (RDS) which is a part of Amazon Web Services. The database is encrypted using the industry standard .
Database technology
Bubble uses PostgreSQL – an open source database management system. In other words, we have not invented a new kind of database system, but use one that has 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 creating 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, let's say we have a "User" data type and a "Post" data type, and we want to create a relationship between them such that each post is associated with a user. In Bubble, we would create a field in the "Post" table with the data type "User", which would represent a reference to a user record in the "User" table.
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
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.
