Does Confluence Database slows down if you add more rows and columns?

[Ayesha Ibrahim]

We have been working on building a list of Project Directory within Confluence Database using the Table Layout for our organisation with all the key Confluence doc links and some columns specifying stage/status of a project/piece of work. We are also using it to track key ETAs from the team like end of dev, start of testing etc. Its easy to say that this Database will have a lot links to epics, docs, next action notes and dates, so do you think this impacts a Database's performance? Because lately as we have been building up the View and we feel that it takes longer to fill info in, so is that natural? Does adding more data slows down a Database? If yes, then shouldn't a Database be designed to cater for logging lots of data?

Fyi this is our first time trailing something like this, previously we have been utilising Databases for organizing our release notes. 

Any pointers suggestions are welcomed. 

Thanks in advance. 

[Kristian Klima · Accepted solution]

Hi @Ayesha Ibrahim 

It depends on how you configure it.

For example, our DB is based on Page links - and individual columns show page details such as labels, dates, owners, excerpts... at 1200 entries, if you scroll all the way, it does take a while for all the fields to render and populate.

There are times when this feels, subjectively, longer. But generally, yes, the more data the database must pull and/or render, the longer it will take to materialize.

[Ayesha Ibrahim]

thanks Kristian 

I don't we have 1200 entries at the moment but its good to know about your experience, may be need to look at how we can make this a bit more leaner for us. 

Do you think that instead of have one big Confluence Database Table view, we divided into separate sections then we will not feel as much of lag? What does your experience say? 

BTW really appreciate you getting back to my query, thank you

[Kristian Klima]

@Ayesha Ibrahim 

You should consider your needs.

Any database or table will outlive its usefulness quickly if it becomes a) diffucult to contribute to, b) difficult to manage, c) difficult to read (comprehend)

Our big DB serves us well despite its lagginess.

You can create DBs per team, project, etc. You may neec to construct multiple DBs just because one project has different needs, uses different details, etc.

[Ayesha Ibrahim]

Thanks for explaining @Kristian Klima apologies had not been on the community platform recently so missed your message. 

Totally agree with what you said there, also now that we are using DBs I am finding them quite valuable. And slowness has not been reported recently plus I creating Views within our DB has also helped. 

Regards