Short answer. Use a table when the rows belong to the text around them: a budget inside a proposal, a comparison inside a specification. Use a database when the rows are the point and people will filter, sort and keep adding to them: a register of documents, assets, risks, suppliers. And before you commit either way, check how the data comes back out, because that is where both of them disappoint people.
What a database actually gives you
A Confluence database is a separate piece of content that lives in the space tree, next to pages, with permissions handled at the space level like everything else. You create it from the Create menu, from the plus next to Content in the sidebar, or by typing /database.
What you get that a table cannot do:
- Typed fields. A date is a date, an owner is a person, a link is a link. Confluence knows what the value means instead of treating everything as text.
- Filters. Filter by a field with real conditions, is, is not, contains, and work with the result.
- Saved views. The same data shown several ways, each view keeping its own filters and sorting, so "open items only" and "everything by owner" are two clicks, not two tables.
- Aggregates. A sum or an average at the bottom of a field, saved as part of the view.
- One source, many pages. The database can be shown on the pages that need it instead of being copied into each of them.
What a plain table gives you
Less, and that is sometimes the right answer. A table sits inside the page, in the flow of the text, and is written and read together with it. It takes any layout you like, including merged cells and mixed content in a cell. Readers can sort it by a column while viewing the page, ascending or descending.
No setup, no separate object to find, no permissions of its own to think about. For a table that exists to support the paragraph above it, that is the whole requirement.
Where the database stops
| Limit | What it means in practice |
|---|---|
| No per-row formulas | You cannot make a column that computes amount multiplied by rate. Aggregates at the bottom of a field exist, per-row calculation does not. Atlassian has an open suggestion, CONFCLOUD-78459, and until it ships the workaround is to calculate elsewhere and type the result in. |
| Export is manual | CSV, HTML or PDF, exported by a person from the database. Fine occasionally. There is no practical way to pull the content through the Cloud REST API, so a scheduled export or a feed into a reporting tool is not something you can build today. |
| Size | No published row limit, but large databases get slow, and community reports describe imports of a few thousand rows with many columns failing outright. Test with your own data before migrating a big register. |
| It is not a spreadsheet | People arrive expecting Excel behaviour, cells referring to other cells, and that model does not exist here at all. |
The formula gap is the one that catches teams out. A register of invoices where the total has to be quantity times price looks like an obvious fit for a database right until you try to build that column.
Where the table stops
- No filters. Sorting by a column exists for readers, filtering does not. A hundred-row table is a hundred rows for everybody.
- Merged cells switch sorting off for the whole table, and merged cells are exactly what people use to make a table readable.
- Nothing is typed. A date in a cell is a piece of text that looks like a date, which is why the same column ends up holding 16/09/2026, Sep 16 and "next Tuesday".
- No export at all. Confluence exports whole pages to PDF and Word, and has no built-in way to send a table to Excel or CSV.
How to choose, in one question
Ask what happens if you delete the surrounding page. If the rows should survive, they are a register and belong in a database. If the rows make no sense without the paragraphs around them, they belong in a table on that page.
A second question worth asking early: who needs this data outside Confluence, and how often. Monthly, by hand, from one place is a different answer from every week, from forty pages, into a finance spreadsheet.
Getting the data back out
This is the part that decides more cases than any feature comparison. A database exports itself to CSV, HTML or PDF, which covers the occasional manual export and nothing beyond it. A table on a page has no export at all: you select it, copy it, paste it into a spreadsheet, and discover that merged cells shifted the columns after the first merge, silently, while the numbers still look perfectly reasonable.
For one table today, copy and paste and be done. The arithmetic changes when it is the same tables every month, from pages spread across a space, and when the shifted column ends up in a report that somebody signs.
Disclosure: I build Table Export for Confluence, which covers that last case: one table, a whole page, or every table in a space into a single Excel workbook, each sheet labelled with the page it came from, with merged cells expanded so the columns stay aligned. It works on tables in pages, not on databases, which export themselves. It runs inside Atlassian's infrastructure, so page content is read in your own site and nothing is sent to me.
If your data already lives in a database and you export it twice a year, use the built-in CSV and spend nothing. Most cases genuinely are that simple.
Questions people ask
Can a database replace a spreadsheet?
Not while there are no per-row formulas. It replaces a list you were keeping in a spreadsheet for lack of anywhere better, which is a large share of such spreadsheets, but it does not replace a model where cells depend on each other.
Can I show a database on a page?
Yes, and that is the normal way to use one: the data lives in the database, and the pages that need it show it. That is the main structural advantage over tables, which have to be copied.
Do database permissions work separately from the space?
Database access follows Confluence content permissions and is managed at the space level, the same as pages. There is no separate permission system to learn, which also means no per-row visibility.
Should I migrate my existing tables into databases?
Only the ones that are registers. Moving a table that explains a document into a database makes the document worse and helps nobody. And test with a copy first if the table is large.
