Bubble.io Database Tutorial: Data Types, Fields, and Privacy Rules
The database is the foundation of every Bubble app. Every field type in a reference table, relationship patterns, and a complete privacy rule code library covering every use case — with the FAQ beginners ask most.
Bubble’s Database: The Most Important Skill to Learn
Every Bubble application is built on a database. The data types you create, the fields you define, the relationships you establish, and the privacy rules you configure determine whether your app is secure, performant, and scalable. Most beginners rush through the database to get to the visual design. This is backwards. The database is the foundation. Everything else rests on it.
Understanding the Core Concepts
Data Type = Database Table
A data type defines the structure for a category of records. ‘Task’ is a data type. Every task a user creates is one record in the Task table. The data type defines what fields each record has.
Field = Column
A field stores one piece of information per record. A Task might have: title (text), is_done (yes/no), due_date (date), and assigned_to (User).
Relationship = Foreign Key
When a field’s type is another data type, it stores a reference to a record of that type. Task’s ‘project’ field of type Project stores which Project this Task belongs to.
Every Field Type in Bubble
| Field Type | Stores | Best For |
|---|---|---|
| text | String of characters | Names, titles, descriptions |
| number | Integer or decimal | Prices, counts, scores |
| yes/no | Boolean (true/false) | Flags: is_active, is_deleted, has_paid |
| date | Date and time with timezone | Created dates, due dates, expiry dates |
| image | Reference to uploaded image | Profile photos, product images |
| file | Reference to any uploaded file | PDFs, documents, attachments |
| option set | Choice from a predefined list | Status, role, category, priority |
| [Data type] | Reference to one record | Task’s project (Project type) |
| list of [type] | Multiple values of same type | User’s skills (list of text) |
The Server-Side Security Layer You Cannot Skip
Privacy rules control who can find, view, edit, and delete records. They run on Bubble’s PostgreSQL database before any data reaches the browser. Without them, authenticated users can access any record via the Bubble Data API. With correct rules, access is architecturally enforced.
Condition
: Search for Memberships [
user = Current User,
workspace = This Record’s workspace,
status = Active
]:count > 0
Permissions
: Find ✓ View all fields ✓
// Creator-only rule (personal records)
Condition
: This Record’s created_by = Current User
Permissions
: Find ✓ View ✓ Edit ✓ Delete ✓
Q: What happens if I have no privacy rules?
Without privacy rules, all authenticated users can find and view all records of that data type via the Data API. This is a critical security vulnerability for any multi-user application.
Q: Can I have multiple privacy rules on one data type?
Yes. Bubble grants access if any one rule’s condition is satisfied. Use multiple rules to allow access to different user categories.
Q: Do privacy rules affect performance?
Well-written rules have minimal performance impact. Poorly written rules that trigger expensive sub-searches can slow queries. Keep conditions simple.
Build Your Bubble.io App With Expert Help
Pakistan’s leading Bubble.io development team. Multi-tenant SaaS architecture, Stripe billing, and full product builds done right from day one.
