Kanboard performance 2024


I’m evaluating Kanboard for a small team (10 users), and so far, I really like the tool.

But I would like to know what’s the state of the performance of Kanboard when the task number starts to be big.

Here, there were problems reported, and even fguillot admitted there was room for improvement: performance drastically deteriorates as task quantity increases · Issue #3822 · kanboard/kanboard · GitHub

It looks like some users pointed at using SQLite as the main cause of their problems, and that using MySQL improved significantly the performance. But it is not clear that was the main cause…

There was a more recent thread here, but I’m not sure of the conclusions:

So, anyone knows if the performance issues were confirmed, and what’s the state of it in recent versions of Kanboard?

Thank you!

As there’s a link limit of 2 per post, I continue here.

Here, there’s another thread where performance issues are reported and it looks like again, SQLite is the reason pointed out:

you quoted me.

i run on mysql. server is on local lan, an ubuntu VM on an older hyperv server.

all my users are on i3 12th gens., no issues with performance. the bottleneck comes down to rendering the board on the users workstations and cpu single core performance. the i3-12th with built in graphics works great.

this is with no filters on viewing the board - tasks are fully expanded (not collapsed) - all open tasks & swimlanes up to 300-400 tasks. 34 columns , 7 swimlanes. all my tasks are work orders generated in an erp system on ms sql. i then sync each work order over to kanboard. work orders contain extensive instructions (in markup) for manufacturing individual parts. there are sub tasks on each main task. tags on each task. users assigned. so on board view all that info is there.

im still on 1.2.12. this is because i have ms sql/mysql backends sync both ways with python and php - some scripts on ubuntu, some on windows. it would take some work to get my scripts updated for newer versions of php and possibly python.

we are very happy with performance at this point.


You read correctly
SQLite is the bottleneck as soon as you have multiple parallel users since SQLite is filebased and only one process/person can write to a file at the same time

Kanboard keeps track of a lot of activities for example to provide a change-history for tasks
These activities create constant strain on the database.

MySQL and Postgres don’t have this constraint and won’t be an performance issue there.

After that the amount of tickets in a board becomes the limiting factor in the browser.
We mitigate this with an “active” work board and then separate “Archive”- and “Ticket-Pool”-Boards