I’d like to get involved in an effort to improve the web interface response times in Roundcube and Nextcloud, so I’d like to get a feeling of how much support there is for this.
I intend to create a prompt / flag during installation to allow an installer to choose to use Postgres rather than SQLite as database
I don’t want to create a fork and let it diverge from MiaB over time (as what happened to PMiaB), but would rather get the support of all those that would like to use such a feature.
I think that for a setup that has multiple domains and between 10 to 100 users per domain, this will make a significant difference.
I do understand that for a personal mail server for less that 5 users, the memory footprint for SQLite would be much smaller, hence my proposal that an installer can choose which option is most suitable.
I always like performance improvements, even if I wouldn’t need them like in this case.
However, I wonder if replacing the database is the most efficient way of getting faster Roundcube for larger deployments. I would first investigate PHP and dovecot tuning options, because those two seem much more important in webmail performance.
Like @KiekerJan, in general improvements are good. But beware of the costs and side-effects of “improvements”. MIAB is popular because it is reasonably lightweight and reasonable simple.
It looks to me that the performance differences between SQLite and Postgres are much more complex than just “x is faster than y”. It’s more “x does A faster, but does B much slower”, so a simple change of DB server isn’t guaranteed to have the desired outcome.
I believe SQLite has some performance tuning options (write-ahead caching, sync v. async updates, etc). It might be an easy win to look into tuning SQLite for small and for large MIAB installs - caching and sync options, buffer and page sizes, indexes, etc.
Sorry, I won’t accept any pull request that changes the database. This project is already too hard for me to lead given the little time I have left for it, and changing the database cannot make that problem any better.
The only changes I’m likely to consider this year are security/accessibility fixes and support for the upcoming Ubuntu 26.04.
From my perspective, anyone is completely welcome to fork the project, and even encouraged. It’s very unlikely at this point that we’ll ever support an Ubuntu version beyond 26.04 (and getting just to 26.04 may be difficult/risky).
I value this project a lot. Josh how can I (we) help you. I know all the irons you have in the fire with other projects.
I would propose we start with just a group of people having broad skill sets and collectively work on those priorities that Josh is setting for 2026. We can start with a team chat platform going maybe on Mattermost or Matrix/Element or Discord or we just keep it within discussion forums here to make more accessible to anyone.