Short version: you cannot export a Confluence database to Excel directly. The database exports to CSV, and Excel opens the CSV. That is a one-minute job, and everything worth knowing here is about what happens afterwards.
The steps
Open the database, open the more menu (the three dots) at its top right, choose Export, and pick a format. Atlassian documents three: CSV, HTML and PDF. CSV is the one for a spreadsheet, and Atlassian describes it as "ideal for importing data into other database tools or spreadsheets". There is no XLSX option anywhere in that menu.
One checkbox matters: Export with current view. Ticked, the export keeps the view you are looking at. Left alone, you get all the data in a plain table layout. If you spent an afternoon building a filtered view for the finance team, that tick is the difference between sending them their view and sending them the whole database.
What the database already does, before you export anything
People export to Excel for two different reasons, and only one of them needs Excel.
If the reason is arithmetic, look under the field first. A Confluence database can show calculations beneath a column: for number fields Sum, Average, Min, Max, Count values, Count unique values, Count empty and Percent empty; for other field types the four counting ones. You turn one on by picking Calculate under the field. A total that lives in the database stays right when the data changes, which a total in last month's spreadsheet does not.
What the documentation does not describe anywhere is formulas or calculated columns: there is no documented way to make one field compute from another. So if your case is a running cost column, the export to Excel is not a workaround, it is the only route.
The trap is on the way back
Exporting is easy. Bringing the data home is where people lose an evening, and Atlassian documents exactly why.
Import into a database takes CSV only. During that import, dates are read month first. The documentation is blunt about it: "Confluence databases assume month comes first for dates, so 12/06/2025 will be treated as December 6, 2025" rather than Jun 12, 2025. It also states plainly: "We do not support date field through autoconversion/autodetection." So a European-formatted date column comes back as a different set of dates, quietly, in the rows where the day is twelve or lower. The rows where the day is above twelve are the lucky ones, because those break loudly.
Two more documented surprises from the same page. Text columns can arrive as tag fields: "String fields in CSV may get converted to tag fields", which happens when most of the values repeat. And the first row of your CSV becomes the field names, with duplicates renamed automatically.
What to do. Before a round trip, switch date columns to an unambiguous form, ISO style, year first. Import one copy into an empty test database and look at February before you touch the real one. And when the import offers you a choice between creating new fields, adding to existing fields and replacing the entire database, read that dialog twice: the third option does what it says.
The arithmetic, if you do this monthly
One database is a minute of clicking. The cost appears when the answer lives in several of them.
Each database is exported from its own menu, one at a time, and each download lands as its own file. Twelve databases across a space is roughly ten to fifteen minutes of clicking and renaming, plus the merge afterwards, and it repeats every month because the export is a snapshot rather than a link. That is not a disaster, it is a standing appointment with an evening.
Worth knowing before you plan around it: databases are not available in the Atlassian Government environment, and the documentation lists other things they do not work with, including anonymous access, admin key, Atlassian Analytics, Atlassian Data Lake, data connectors, screen readers and keyboard navigation, and some Marketplace apps. Atlassian says that list is not exhaustive.
Two questions people expect answered here, and the honest answer to both is that the documentation is silent. It says nothing about which plans include databases: the only availability limit stated is the Government environment one. And it does not say whether databases are included in a space export, in either direction; the space export page lists blog posts, comments and Team Calendars as exclusions and never mentions databases. If either point matters to your migration, test it on one space rather than trusting an article, including this one.
If your data is not in a database at all
Half the people who search for this do not have a database. They have ordinary tables on ordinary pages, which look similar and behave nothing alike: no export menu, no calculations under the column, and no CSV.
Disclosure: I build Table Export, which covers that second case, taking one table, a page, or every table in a space into a single workbook with a sheet per table. It does not replace the database export: if your data is in a database, the built-in CSV export above already does the job and you do not need my app. That is the honest split, and it costs me nothing to say, because half of these searches genuinely end at the Atlassian menu.
Frequently asked
Does the export include the calculations shown under a field? The documentation does not say. Treat the export as the rows, recreate totals in the spreadsheet, and check the first file you send anyone.
Can I get the data out without downloading files by hand? Not through the documented database export, which is a per-database menu action. If you need it scheduled, the honest answer is that this is a script-and-API job, not a menu one.
Why not just use HTML export? It is genuinely useful for one thing the CSV cannot do: Atlassian notes the HTML export gives you the option to copy the data to the clipboard, which is faster when you only need to paste a small table into an email.
