---
title: "Your site's database: collections and records | Briks"
url: https://briks.dev/docs/database
description: "Find what your site stores, edit and add records by hand, and download collections as JSON or CSV, with who can do what and the limits that apply."
last_updated: 2026-10-08
---

# Your site's database: collections and records

When your site keeps things that change, such as blog posts, products, events or booking requests, Briks stores them in the project's own database. This page shows you where to find that data, how to change it by hand, how to add new records and how to take a copy away.

9 minute read Checked against the studio on 8 October 2026

## What the database holds

A database is where a site keeps information that changes, separate from its design. Briks sorts it into **collections**, one for each kind of thing the site stores: Class requests, Teachers, Blog posts. Each collection holds **records** (one class request, one teacher, one post), and each record has **fields**, such as a name, a date or a picture.

Your pages read the records when the site is published. So when you change a record, you don't need a new build: the studio publishes the site again for you, and the change shows within a few minutes.

### When a project gets one

Most projects get a database without anyone asking for one. Briks makes it the moment a build needs to store something: a blog you can update yourself, a menu, a list of events, or a page where people send a booking request. Ask for what you need in the studio and the database is made for you, in the European Union.

Until a project has a database, only Owners and Admins see its **Database** tab, where they can choose **Create database** to make an empty one. Everyone else sees the tab once a database exists.

Where the tabs are

A project's tabs sit in a row of words under its name in the top bar: **Studio**, **Analytics**, **Media**, **Database**, **Storage**, **Chatbot** and **Settings**. Some projects also show **Visual Editor** after Studio and **Marketing** after Analytics. On a phone the row scrolls sideways.

## Find your way around the Database tab

Where

1. Projects
2. Your project
3. Database

The tab has five views along the top:

| View | What it shows |
| --- | --- |
| **Data** | Your collections down the left, each with the number of records it holds, and the chosen collection's records beside them. |
| **Accounts** | The people who made an account on the site, if the site has sign-in for its visitors. Until someone signs up, the view says **No accounts yet**. See [Sign-in and payments](https://briks.dev/docs/sign-in-and-payments). |
| **Orders** | What the site sold through your own payment processor, newest first: when, what for, the amount, its state and the buyer. Refunds are made in the processor's own dashboard. Until the first sale, the view says **No orders yet**. |
| **Subscriptions** | The plans members pay for that renew: who subscribed, the plan, its state, and when it renews or ends, with the monthly income from running live plans. Members cancel on the processor's own page, and you in its dashboard. See [Sign-in and payments](https://briks.dev/docs/sign-in-and-payments). |
| **Settings** | What the database holds and where it is kept, downloads, restore points, the nightly copy and the danger zone. |

If a line starting **Not shown:** appears under the collections, the site describes those collections in a way the tab can't read. Ask the studio to fix how they are described.

Browse a collection

1. Pick the collection

   Where: Database, Data

   Click its name in the list on the left. On a phone the list runs across the top instead. The list on the right shows that collection's records, 25 at a time.

2. Search it

   Where: Database, Data

   Type in the search box (it reads, for example, `Search class requests`) and press **Search**. Choose **Clear** to see everything again.

3. Sort by a column

   Where: Database, Data

   Click a column heading to sort by it, and click it again to reverse the order. A small arrow shows which way the list runs.

4. Move between pages

   Where: Database, Data

   When there are more than 25 records, use **Previous** and **Next** under the list.

5. Switch language

   Where: Database, Data

   If a collection is kept in more than one language, buttons with each language's name appear beside the search. Each language has its own records.

6. Refresh

   Where: Database, Data

   Records the site saved since you opened the page, such as a new booking request, appear when you press **Refresh**, the round arrows beside the collection's name.

## Edit a record

1. Open it

   Where: Database, Data

   Click the record's name in the first column, or open the three dots at the end of its row and choose **Edit**.

2. Change the fields

   Where: Edit dialog

   Each field has an input that suits it: a text box, a rich text box with a small toolbar (bold, italic, headings, lists, quotes and links), a number, a date, an on and off switch, a list to choose from, or a picker for a record in another collection. Dates with a time are in your own time zone.

3. Check the address and status

   Where: Edit dialog

   Collections whose records have their own pages show a **Slug**: the last part of the record's address, such as `my-first-post`. Leave it empty and it is made from the title. **Status** is **Draft** or **Published**, and drafts stay off the published site.

4. Save

   Where: Edit dialog

   Press **Save**. If a value isn't accepted, the field says what to change. When it works you see: Saved. The published site catches up within a few minutes.

A picture field takes the picture's path in the project's storage, a path on the site such as `/images/cover.webp`, or a full https address. To use a new picture, upload it to [Storage](https://briks.dev/docs/storage) first and give its path.

## Add a record

1. Press the add button

   Where: Database, Data

   Above the list, press the button named after the collection, such as **Add class request**. In an empty collection the same button also sits in the middle of the page.

2. Fill in the fields

   Where: Add dialog

   Fields marked optional can stay empty. In a collection kept in several languages, the record is added in the language you are looking at.

3. Add it

   Where: Add dialog

   Press the button at the bottom, which repeats the add label. The record joins the list, and the live site shows it within a few minutes if its status is **Published**.

Deleting a record

Open the three dots on its row and choose **Delete**. The dialog warns that it cannot be undone, and from there it can't. A restore to a moment before the delete can still bring it back while the database's history reaches that far. See [Backups](https://briks.dev/docs/backups).

### How quickly changes reach the live site

After you add, change or delete records, the site is published again on its own: straight away the first time, then at most once every five minutes, however many edits you make. If a build or an A/B test is running, the update waits and tries again a couple of minutes later. Nothing is published before the site's first publish. Each change can also tell another tool through a `record.changed` [webhook](https://briks.dev/docs/webhooks).

## Download your records

Downloads sit in the **Export** group of the Database tab's **Settings**, and both rows carry a **Paid** tag: they come with a paid plan. On the Free plan each row reads: Comes with a paid plan. A note above the group says the same, and its **See what's included** button opens the upgrade window with the smallest paid plan. More on plans in [Billing](https://briks.dev/docs/billing).

Where

1. Projects
2. Your project
3. Database
4. Settings
5. Export

| Download | What you get |
| --- | --- |
| **Download everything** | Every collection in one .zip: a `collections.json` file describing how each collection is made up, and one JSON file per collection with its records. |
| **Download a collection as a spreadsheet** | One collection as CSV: a column for the record's id, then its slug, status, language and dates where the collection has them, then one column per field. |

JSON is a plain text format other software reads easily. CSV is the format every spreadsheet app opens. Each download takes up to 50,000 records per collection. If a collection holds more, the .zip includes a `README.txt` that names it, and you can write to hello@briks.dev for the rest.

Anyone in the workspace who can see the project can download, Viewers included. A project allows up to 30 downloads an hour.

Export one collection to a spreadsheet

1. Open the settings

   Where: Database

   Open the Database tab and choose **Settings** along the top.

2. Choose the collection

   Where: Settings, Export

   In **Download a collection as a spreadsheet**, pick it from the list beside the button.

3. Download and open it

   Where: Settings, Export

   Press **Download**. The file is named after the site, the collection and today's date, such as `lotus-room-class_requests-2026-10-08.csv`, and opens in any spreadsheet app with one row per record.

## Who can do what

| Action | Who can do it |
| --- | --- |
| See collections and records | Everyone in the workspace |
| Add, change and delete records | Editors, Admins and Owners |
| Download records (paid plans) | Everyone who can see the project |
| Save a restore point, switch the nightly copy on or off | Editors, Admins and Owners |
| Restore, clear a collection, delete the database | Owners and Admins, with the project's name typed |
| Create the database by hand | Owners and Admins |

A Viewer who opens a record sees it read only, with the line: You can look but not change records in this workspace. Roles are explained in [Members and roles](https://briks.dev/docs/members-and-roles).

## The Accounts view

If your site keeps accounts for its visitors, **Accounts** lists them: name and email, role, whether their email is confirmed, when they joined and when they last signed in. You can search by email or name, and sort by the column headings. Each row's three dots offer:

- **Change role**: sets the account to **Member**, **Staff** or **Admin**. It applies the next time they open a page on the site, and they stay signed in. Editors and above.
- **Sign out everywhere**: ends their sessions on every device at once. They can sign in again with their password. Editors and above.
- **Delete account**: removes their account, password and sessions for good, after you type their email. Anything else the site keeps for them stays. Owners and Admins.

## Worked example: a yoga studio's class requests

Brief Lotus Room Yoga, Bristol

> A page where people can ask for a place in a class: their name, email, the class they want and a note. Keep every request so I can go through them each morning.

The site went live with a request form, and the project gained a **Database** tab with a **Class requests** collection. Each request a visitor sends is a record there.

Each morning the studio manager opens **Database**, picks **Class requests** and clicks the date column so the newest requests come first. When a request needs a closer look, she clicks the visitor's name to open it.

A change by hand

> A request for Thursday's yin class came in with a typo in the email address. She opens the record, corrects the address and presses **Save**.

Saved. The published site catches up within a few minutes.

At the end of the month the owner downloads **Class requests** as a spreadsheet to count requests per class and plan the next timetable. That download needs a paid plan.

### I changed a record but the live site still shows the old one.

Give it a few minutes. The site is published again at most once every five minutes, and the update waits while a build or an A/B test is running. Check the record's status is **Published**, not **Draft**.

### Can I add a field or a whole collection here?

Not from the Database tab. Ask in the studio, for example: add a phone number field to class requests. Briks saves a restore point before it changes how the database is made up.

## Read next

- [Data and automation **Backups** What Briks keeps of each project: code versions, database restore points and nightly copies. How to restore, how to download and what each copy holds.](https://briks.dev/docs/backups)
- [Data and automation **Webhooks** Send a signed message to another tool when your site is published, a form is sent or a record changes. Payloads, signatures, retries and deliveries explained.](https://briks.dev/docs/webhooks)
- [Your site's features **Forms** Add a form to your Briks site, test it in preview, find every entry in the studio, get each one by email in production and pass them on with a webhook.](https://briks.dev/docs/forms)
- [Workspaces and account **Members and roles** Invite people by emailed link and give each one a role: Owner, Admin, Editor or Viewer. See what each role can do and how many people each plan holds.](https://briks.dev/docs/members-and-roles)

Still stuck?

Write to [hello@briks.dev](mailto:hello@briks.dev) with your project's name and what you expected to see. A screenshot helps.