Linking Confluence Databases: From Dishes to Ingredients

[#1]

Hello Atlassian Community!

One of the most powerful and fun ways to use Confluence Databases in Cloud is to connect two sets of related information. Let’s walk through a real example I used to introduce the concept to my team, using something everyone understands: Food!

Step 1: Creating the Dishes Database

Our first database contains the dishes themselves.
Each entry includes:

• Dish Name (e.g: Idli, Biryani, Dhokla, Ramen)
• Cook Time (in minutes)
• Region (e.g: Tamil Nadu, Andhra Pradesh, Japan)
• Vegetarian (Yes/No)
• Cost (optional)

Already, this lets us sort, filter, and group dishes by cook time, cuisine, or diet preferences.

Step 2: Building the Ingredients Database

The second database contains details for each dish’s building blocks:

• Dish Name (linked to the Dishes Database)
• Ingredient Name (comma-separated)
• Spice Level (Low, Moderate, High)
• Glimpse (an image of the dish for quick recognition)

Step 3: Linking the Two

The magic happens when we link the Dish Name field in the Ingredients Database to its matching entry in the Dishes Database.
This means:

• Clicking on “Idli” in the ingredients table takes you straight to its main dish entry.
• Any updates to a dish, like changing its region or cook time, automatically reflect everywhere it’s referenced.
• You can embed either database into any Confluence page, with filters and views tailored for the audience.

The Recipe Behind the Magic

Even though this is a food example, the principle applies to any project:

• Dishes = Projects, Features, Campaigns, or Events
• Ingredients = Tasks, Requirements, Assets, or Stakeholders

By separating and linking related data, you avoid duplication, keep everything consistent, and make it easier to explore relationships between items.

From Kitchen Experiments to Team Excellence

Next time you’re explaining linked databases to your team, don’t start with epics and tasks. Start with something everyone loves talking about, like dumplings or dal. You might just inspire your next lunch and your next Confluence workflow at the same time.😊

[Patrick S. Stuckenberger]

I still do not get why this should be useful. 

you can use a normale table and link it. 

you have no change history in the "database"

[Bill Howard]

I think this is a cute example, but I agree that it really doesn't solve a problem that isn't already solved more easily with standard Confluence tables, and for me, that's the whole problem with Confluence databases to date.  Until databases have the same kind of capabilities that I get using the table toolbox along with page properties and page property reports, I really can't use them, as much as I'd love to.

[Rajat Pratap Singh]

Hi @Patrick S. Stuckenberger 

That’s a fair point. If all you need is a static table, a regular Confluence table with links can work just fine.

Where Databases shine is when your information needs to be:

• Structured with specific field types (status, people, dates, page links, dropdowns)
• Reused across multiple pages without copy-pasting
• Filtered and sorted dynamically by different teams or contexts
• Linked to other databases to show relationships between items (like Stories -> Task)
• Viewed in multiple formats (table, board, card) without changing the source data

On the version history side, databases do keep a history of changes, but it’s currently limited to the past 30 days.

Hope this helps!

Regards
Rajat

[Raquel Cueto-Senra]

Agree with other commenters, but also this example doesn't really highlight its capabilities and, at least from my perspective, it's badly structured and leads to confusion to people that don't really use databases.

For example, I would expect that an ingredients database would store information about, well, ingredients, however each entry in it is a combination of ingredients used in a particular recipe. The dishes database should contain spice level and image per dish, however you do that in the ingredients database instead.

If you wanted to highlight this capability better, you would have one entry per ingredient in the ingredients database, which would also have a column in which you would dynamically show which dishes -from the dishes database- they are used. You could also have a column in the ingredients database that shows which type of ingredient it is i.e. meat, vegetable, spice, etc. The dishes database would have a column linked to the ingredients database in which you would select which ingredients the dish uses, and maybe you could have another column that would show the type of ingredients as well, also linked directly to the ingredients database.

Overall, I think this is a bad example.

[Dan Duett]

@Rajat Pratap Singh: Unlike some of the folks commenting, I do understand the value of relational data and linked database entries and was an enthusiastic early adopter.

We have a couple database fields that could've been tags but that I opted to make linked entries. I was then dismayed to learn that the sort order isn't alphabetical or controllable—which many would consider a bug or design defect, but Atlassian apparently considers a feature request. Linked entries are also very hard to differentiate—again, a design defect. If we don't improvements in one or both of these areas, I'll probably revert those fields to tags, which would be a shame, because I see the value in this field type.

Can you help advocate internally for addressing the above? I think it'll really help smooth the adoption process and make it a more compelling/usable field type.