[fat-flatpak-intro.png]

Something that often catches people off guard when using a desktop Linux distribution is that Flatpak applications consume a lot of storage space.

A handful of applications that would take a few hundred megabytes as traditional packages somehow balloon into multiple gigabytes when installed via Flatpak.

So what’s going on? Why does installing a simple text editor as Flatpak requires hundreds of MB when the native package version requires minimal storage space?


The Dependency Problem Flatpak Solves

On traditional Linux systems, applications rely on shared system libraries. This is efficient, for example, if 10 applications all need the same library, it’s only stored once on disk.

This however, creates a couple of problems:

  • Version Conflicts: App A needs library version 1.2, but app B needs version 1.5.
  • Distribution Fragmentation: An app built for Ubuntu might not work on Fedora due to different library versions.
  • System Updates Breaking Apps: A system library update could break apps that relied on the old version.

For Flatpaks, each application brings its own dependencies and runs in an isolated sandbox. No more dependency conflicts, and no more worrying about system updates breaking things, however the trade-off is storage space…


How Flatpak Uses Storage

Flatpak’s storage model consists of 3 main components:


Applications

These are the actual programs you install. Each Flatpak application is self-contained in its own sandbox and includes any dependencies that aren’t provided by its runtime.


Runtimes

Runtimes are shared foundations that provide common dependencies for applications. Instead of every single app bundling GTK, Qt, or core system libraries, apps can depend on a runtime that provides these.

The major runtimes include:

  • Freedesktop: The base runtime providing core libraries and toolchains.
  • GNOME: Built on Freedesktop, adds GNOME-specific libraries.
  • KDE: Built on Freedesktop, adds Qt and KDE libraries.

Repository

Flatpak uses OSTree to store files in /var/lib/flatpak for system-wide installations or ~/.local/share/flatpak for user installations. This repository contains all the actual data that apps and runtimes are built from.


Why the Numbers Look Worse Than They Are

Flatpak uses hard links for deduplication. When multiple apps or runtimes share the same file, Flatpak doesn’t duplicate it - it creates hard links pointing to the same data on disk. This means a file might appear in multiple places, but it’s only stored once.

The problem? Standard tools like du count hard links separately, making it appear that you’re using far more space than you actually are.

For example, if you run:

du -sh /var/lib/flatpak

You might see something like 15 GB. But the actual disk usage (counting deduplicated data) could be closer to 8-10 GB. Tools that understand hard links will give you a more accurate picture.


Deduplication in Flatpaks

Flatpak’s deduplication works at multiple levels:

  • Between Runtimes: The GNOME and KDE runtimes are both build on the Freedesktop base runtime, so they share those common files rather than duplicating them.
  • Between Applications: Apps using the same runtime share those runtime files. Installing a second GNOME app doesn’t require downloading the entire GNOME runtime again.
  • Between versions: When runtimes update, only the changed files are downloaded and stored. Unchanged files are shared between versions.

This is why the first Flatpak application installation might be huge (the entire runtime is downloaded), but subsequent installs are much smaller.


The Real Storage Cost

Despite deduplication, Flatpak does consume more space than traditional package installations because:

  • Multiple Runtime Versions: You might have GNOME runtime 48, and 49 all installed because different apps require different versions. Each version can be hundreds of megabytes.
  • Bundled Dependencies: Apps still bundle dependencies that aren’t in runtimes. An Electron app, for example, might bundle the entire Electron framework, which can take a lot of space.
  • Leftover Runtimes When you uninstall apps, their runtimes might remain on your system until you manually clean them up.

Managing Flatpak Storage

Check What’s Installed

See what’s consuming space:

# List all installed Flatpaks with their sizes
flatpak list --columns=name,application,size

# List only applications (not runtimes)
flatpak list --app --columns=name,size

# List only runtimes
flatpak list --runtime --columns=name,size

Remove Unused Runtimes

When you uninstall apps, their runtimes might stick around (remove them if not needed):

# Remove unused runtimes and extensions
flatpak uninstall --unused

# This is safe and only removes runtimes not used by any installed app

Move to a Different Partition

If your root partition is filling up, you can install Flatpaks to your home partition instead:

# Add the user repository
flatpak remote-add --user flathub https://flathub.org/repo/flathub.flatpakrepo

# Install apps with the --user flag
flatpak install --user flathub org.mozilla.firefox

Is the Space Worth It?

As the universal answer to many questions, it depends…

When Flatpak Makes Sense:

  • You want the latest versions of applications without waiting for distribution updates.
  • You need apps that aren’t available in your distro’s repositories.
  • You value the sandboxing and security isolation of Flatpaks.

When Traditional Packages Might be Better:

  • You have limited storage space.
  • You prefer minimal systems with tight control over what’s installed.
  • The apps you need are already available and up-to-date in your distro’s repos.

Final Thoughts

I personally use a hybrid approach. Flatpak is my default for most desktop applications, as the sandboxing alone makes it worthwhile for anything that touches the internet or handles untrusted files. However, I’m lazy and don’t feel the trouble is worthed for some applications that need deeper system integration that struggle with Flatpak isolation/permissions (which can be configured to allow access as needed).

The storage overhead is real, however today, with cheap SSD/HDDs, the tradeoff usually makes sense most of the time. This however, depends on your use case (and patience).