Does the Plasma community have plans to improve or lightweight KDE PIM?

[sincorchetes]

Hi everyone,

​I’ve been a long-time user of KDE Plasma, and while the desktop environment itself is lighter and more modular than ever, KDE PIM (Kontact, KMail, KOrganizer) still feels massively overweight for modern, minimal use cases.

​My specific pain point is that I only need to sync my Google Accounts to have my calendar integrated into the desktop.

​To achieve just this, the system spins up the entire Akonadi framework with its underlying database instance (MySQL/PostgreSQL), multiple background agents, and a massive memory footprint. It feels like cracking a nut with a sledgehammer.

• ​Pros of the current stack: It is an incredibly powerful, enterprise-grade groupware suite for offline management if you need full local indexing.

• ​Cons: For users who rely primarily on cloud sync (like Google Calendar, CalDAV, or EWS) and just want basic desktop integration, the resource overhead, background idle usage, and configuration complexity are disproportionately high.

​My questions to the community and developers:

1. ​Is there any technical roadmap or active effort in the Plasma 6 lifecycle to decouple simple calendar/contact syncing from the heavy Akonadi database architecture?

2. ​Are there lighter official alternatives being cooked up (perhaps leveraging Kankou, Kalendar/KOrganizer split, or native Plasma widgets that fetch directly via APIs) to bypass the full PIM suite entirely?

​I would love to know if the community shares this feeling or if there are better, lightweight workarounds that I might be missing for modern, cloud-centric workflows.

​Thanks!

[krake]

@sincorchetes

KDE PIM (Kontact, KMail, KOrganizer) still feels massively overweight for modern, minimal use cases.

Maybe give the Merkuro Suite a try.

@sincorchetes

its underlying database instance (MySQL/PostgreSQL)

I think it defaults to Sqlite nowadays.

[sincorchetes]

Thanks for the suggestion! However, regarding Merkuro and the database backend, there are a couple of technical misconceptions here:

Merkuro is just a Kirigami-based frontend: While Merkuro (formerly Kalendar) features a beautiful, modern, and adaptive UI, it is still built directly on top of the KDE PIM / Akonadi framework. Under the hood, it spawns the exact same Akonadi server, agents, and storage architecture to handle calendar syncing. It mitigates the UI heaviness, but not the backend overhead.

The Database Myth (MariaDB vs. SQLite): Akonadi does not default to SQLite for production use. According to KDE’s own documentation, Akonadi uses MariaDB/MySQL as its default internal database driver because SQLite has known concurrency and locking issues when handling multiple background sync agents simultaneously. Even if you manually force Akonadi to use SQLite, it still runs the full entity-relationship daemon layer, which remains overkill for just fetching a remote Google Calendar API.

My point stands: whether I open KOrganizer or Merkuro, akonadiserver still spins up a full relational database environment in the background just to cache a cloud-hosted .ics file.

Are there any architectural plans in KDE to implement a pure, Akonadi-free direct API sync provider for those who don’t need offline local database indexing?

[krake]

@sincorchetes

While Merkuro (formerly Kalendar) features a beautiful, modern, and adaptive UI, it is still built directly on top of the KDE PIM / Akonadi framework

Yes, exactly!

It can focus on a different user experience without wasting time on reimplementing dozens of connectors. As a bonus all data is automatically available/shared with other apps, e.g. Kontact (or its components), Plasma (e.g. event integration in digital clock), Zanshin task manager, etc.

Most modern platforms have a PIM service to allow single account setup and multiple UIs, though not all can handle as many data types as KDE’s: some can only do calendar, some also contacts, some might even be able to do email.

@sincorchetes

The Database Myth (MariaDB vs. SQLite): Akonadi does not default to SQLite for production use.

Maybe it is distribution dependent.
I am pretty sure the last time I installed KDE Neon a couple of years back it has defaulted to Sqlite and I had to manually install the MySQL backend as this is what my backed-up data required.

@sincorchetes

According to KDE’s own documentation, Akonadi uses MariaDB/MySQL as its default internal database driver because SQLite has known concurrency and locking issues when handling multiple background sync agents simultaneously

I know this was true at the time the first default had to be chosen. Even using MySQL in its embedded variant didn’t work reliably enough, hence the separate process with full capability.

Looking into the repository the build instructions say

* DATABASE_BACKEND (Default: MYSQL, available: MYSQL, POSTGRES, SQLITE): Define which database driver to use by default. MYSQL
  is the default right now, SQLITE is recommended for most users.

However, the actual build file sets SQLITE if not otherwise specified

if(NOT DEFINED DATABASE_BACKEND)
    set(DATABASE_BACKEND
        "SQLITE"
        CACHE STRING
        "The default database backend to use for Akonadi. Can be either MYSQL, POSTGRES or SQLITE"
    )
endif()

So I assume that this is mostly a case of some documentation not having been updated in sync with code and/or build system changes.

@sincorchetes

Are there any architectural plans in KDE to implement a pure, Akonadi-free direct API sync provider for those who don’t need offline local database indexing?

No idea. Probably not likely since a much more versatile API exists and is already being used by apps and applets alike.

However, I vaguely remember some postings here in which people have announced alternative Plasma widgets for things like displaying events from a single remote service. There might also be applications that do that.