Top 4 Reasons Why I Choose Debian vs Ubuntu Server

This updated article was originally published on 2022-06-04.

Today, I approach the question of which Linux distro – Debian vs Ubuntu Server – to deploy on servers? I’ve setup and deployed tons of Linux servers over the years. Many of the servers I deploy are on very small / inexpensive cloud instances – servers with 1 to 2GB of system memory – which weighs heavily into my short list of reasons why I prefer to deploy Debian as my Linux distro of choice on new servers.

Valid Reasons To Choose Ubuntu

Before I get into my reasons for choosing Debian, let me start by mentioning that there are very valid reasons that you might choose to deploy Ubuntu instead of Debian. The point of this article is not to dump all over Ubuntu. I’m not a Linux elitist. There is no one perfect Linux distribution. People who prefer Arch or Ubuntu or Fedora or whatever is fine by me – though, starting a Linux fanboy war would be great for post engagement, that’s not my goal here. I’m happy with people using Linux – period.

With that said, let’s briefly explore why someone might choose Ubuntu Server.

Predictable Software Lifecycle

From the very beginning, Ubuntu has had a very predictable software lifecycle. With one exception in 2006 where a release was pushed back 2 months, Canonical puts out a new release of Ubuntu every April and October with a 9 month support window and LTS versions every two years with 3 years of desktop and 5 years of server support. You always know when to expect the release and you know how long you can run it. In the business world, having this predictable schedule is important for long term planning.

Paid Support From Canonical

Another extremely valid reason to choose Ubuntu over Debian is the availability of paid support from Canonical. The corporate IT world lives and breathes on support contracts. Having this level of support available makes the business decision of choosing Ubuntu make perfect sense.

Now, for the servers I deploy and the way I deploy them, I don’t need a predictable release cycle and I don’t need paid support. What I do care about when deciding between Debian vs Ubuntu Server is …

#4 – Stability Over Newest Features

When you get Linux people talking about Linux – and boy do Linux people love talking about Linux – words you’ll often see mentioned regarding Debian include:

  • dependable
  • reliable
  • stable
  • secure

Debian has been around a LONG time – well long in technology terms anyway. The first release came out in September 1993. Few Linux distributions can claim that kind of longevity. Over that time, Debian’s philosophy of releasing when the bugs are worked out instead of based on a hard release date has earned it this reputation.

The emphasis on bug free / stable software means that the packages included with Debian are usually not the most current versions available. For example, while PHP is up to version 8.2 at the time of writing, the current Debian release (version 12) includes version 8.1 and will continue to do so until Debian 13 is released. While it’s not always desirable in the desktop world to be missing out on the latest features, in the server world security and stability are paramount.

Other software developers benefit, as well, from the stability that Debian provides. For example, the current recommended version of PHP for WordPress is version 7.4. This recommendation tracks behind the current Debian release. By recommending the more mature version, WordPress developers have additional time to test and fix software bugs that might appear with the newer PHP versions. By the time Debian updates their PHP version, there’s a far lesser chance of there being an incompatibility

#3 – Zero Reliance On Snap Packages

While you can easily add support for Canonical’s snap package format to Debian, it doesn’t include it out of the box – which suits me just fine. There’s a lot of, let’s use the word dislike, in the Linux community for snap packages.

I’m not much of a fan of snaps myself, but I will use them when absolutely required. Thankfully, snaps aren’t often found on servers. The notable exceptions to this that come to mind are Canonical’s LXD virtualization / containerization system – which I will admit I actually like and use quite a bit – and Nextcloud. Both are available to install as a snap package.

Could this change at some point in the future, though, as Canonical is said to be releasing an official snap-only version of Ubuntu – called Ubuntu Core Desktop – with the 24.04 release cycle? It’s clear that Canonical is trying hard to push adoption of the package format. At some point I won’t be shocked if they try to push it further into the server space as well.

With that said, the main issues people tend to have with snaps are that they start slowly and often use more system memory than their non-snap counterparts.

Conversely, Ubuntu Server comes preconfigured with snap support. If you’re not actually using it on your server, you can save yourself some system memory by removing it from your system.

#2 – Community vs Corporate Control

As of July 2023, there’s been a great deal of discussion going on in the Linux community on this very topic and I’ve felt it was important to update this article to reflect how important this topic has become for some – myself included.

IBM / RedHat Controversies

If you’re reading this in the future and don’t know what’s events I’m referring to, IBM / RedHat have stirred up a hornet’s nest with their announced change to their stance on making the code to RedHat Enterprise Linux (RHEL) freely available as has been customary since RedHat was founded in 1993.

This isn’t the first time that IBM / RedHat has stirred the ire of the greater community. Following RedHat’s acquisition by IBM, RedHat brought the previously community driven CentOS project – which was a 1:1 bug compatible fork of RHEL – under their control. Once this was done, the distro was rebranded to CentOS Stream and was no-longer a RHEL clone.

Predictably, this caused an uproar that resulted in the creation of two new RHEL clones – Almalinux and Rocky Linux – whose goals were to fill the void left by the loss of CentOS.

It’s absolutely clear that the goal of IBM / RedHat’s change to source code availability is attempt to cause an end to RHEL compatible distros, which effects not just Almalinux and Rocky Linux but Amazon Linux and Oracle Linux as well.

I’m not going to dive into all of the minutia of details on this matter as there’s PLENTY of material out there on the subject already. I’ll link to a few videos, below, for those who want to know more. If you haven’t already, I highly encourage you to watch them.

How This Relates To Debian vs Ubuntu Server

The point to bringing up the controversies regarding IBM / RedHat is to illustrate how a corporate controlled Linux distribution isn’t necessarily looking out for the best interests of their users or the community but are always looking out for their own interests.

An obvious example of how this is apparent regarding Canonical is their aforementioned persistence on pushing snap packages when the community has largely spoken out in favor of alternatives such as Flatpak – a competing package format that is distro independent and is developed by the community.

Even more relevant is the fact that Canonical – hot on the heels of the current RedHat controversy – has announced that they’ve taken over control of the development of LXD containerization software away from the LinuxContainers project – a community based organization. LXD was originally created by Canonical and is built on top of LXC but then turned control over the development to the community while employing developers to work on the project.

This move to retake control over the project has prompted the lead LXD developer – a Canonical employee of 12 years – to resign from Canonical, stating:

As I’ve told colleagues and upper management, Canonical isn’t the company I excitedly joined back in 2011 and it’s not a company that I would want to join today, therefore it shouldn’t be a company that I keep working for either,”

Stéphane Graber

Admittedly, this isn’t nearly as egregious as what RedHat has done but it doesn’t do anything to help engender a feeling of trust with the community at a time when people are considering whether they’ll continue to use RHEL – or any RedHat affiliated distros – in their systems.

Like others in the community, I cannot in good conscience choose a Linux distro that I feel doesn’t always respect the larger open-source community that it was born from. To that end, Debian has been a community developed project since its inception in 1993 and continues that legacy to this day.

#1 – Debian Uses Less Memory

This is where this discussion gets a bit more objective – while everything I’ve previously mentioned was 100% subjective. I’m about to throw some hard data at you to back up my #1 reason to use Debian over Ubuntu Server. Debian uses less memory than Ubuntu.

Simply put, on fresh OS installs, Debian uses less system memory. On larger systems the difference is small enough to not matter much. However, when it comes to small cloud servers, virtual machines, and containers the difference can be substantial.

For my first test, I created a virtual machine using KVM/QEMU with a single CPU and 1GB of memory – a common configuration found on inexpensive cloud servers and then installed both Ubuntu and Debian. The default Ubuntu Server 22.04 ISO was used for Ubuntu and the Debian 11 Netinst ISO was used for Debian. All tests were performed when this article was originally published – hence the now outdated versions.

Let’s start by looking at Ubuntu. During the install I chose the minimized option that is available in 22.04. The only additional software that I installed was SSH, for remote access to the VM, and htop, for checking the system resources. Total memory being used by the system is 153MB out of 971MB reported as available – almost 16% of the total RAM and we don’t even have any applications installed yet.

Debian vs Ubuntu Server - Htop on Fresh Ubuntu 'Minimized' Install
Debian vs Ubuntu Server – htop on Fresh Ubuntu ‘Minimized’ Install

To help Ubuntu, I decided to remove snap support from the system. Total memory use decreased by 6MB down to 147MB. This is still a little over 15% of the total memory.

Debian vs Ubuntu Server - Htop on Ubuntu Without Snaps
Debian vs Ubuntu Server – htop on Ubuntu Without Snaps

Let’s compare, now, against a fresh Debian installation. Again, the only additional software installed is SSH and htop. Here you see that Debian is using just 67MB of 976MB – just under 7% of the total system memory. Notice also that Debian makes 5MB more of the total VM memory available for use than Ubuntu does.

Debian vs Ubuntu Server - Htop on Fresh Debian Install
Debian vs Ubuntu Server – htop on Fresh Debian Install

Having the additional 8 – 9% of the total system RAM available is significant – especially if you are looking to maximize the number of VMs you can run on a server. Twenty Ubuntu based VMs without snapd would need 2940MB of memory just for the base operating system compared to 1340MB with Debian. In fact, forty Debian based VMs would still use less memory – only 2680MB.

To hammer the point home, I thought it worth exploring whether this held true if you used Debian vs Ubuntu Linux container images. For this test, I created two LXD containers – one with Debian 11, the other Ubuntu 22.04 – using the same profile where each container is limited to 1GB of memory. The Ubuntu container already included htop, whereas I had to install it manually in the Debian container.

This comparison takes the kernel differences between the two distros out of the picture entirely, as the host system kernel is being utilized by each container.

Starting again with Ubuntu Server we see the container is using about 90MB of memory. I didn’t bother with a second screenshot, but we can again save about 6MB by removing snap from the system – if needed. Going forward in this comparison we’ll use 84MB as the value to represent the Ubuntu container – 8.8% of the container’s memory.

Debian vs Ubuntu Server - Htop on Ubuntu LXD Container
Debian vs Ubuntu Server – htop on Ubuntu LXD Container

Compare this with the mere 18MB that the Debian container uses – just 1.9% of the container’s total memory and 66MB less than Ubuntu.

Debian vs Ubuntu Server - Htop on Debian LXD Container
Debian vs Ubuntu Server – htop on Debian LXD Container

In short, if memory utilization is important, Debian is the better choice over Ubuntu Server.

Which Would YOU Choose?

Debian vs Ubuntu Server – which would you choose? Would you use neither and go with something else entirely? Tell me what you think in the comments below.

If you found this article helpful and would like to support our efforts to create additional resources like this, please consider making a donation. Your support is greatly appreciated!

If you can’t make a donation, please consider sharing this article with others who may be interested. If you have questions about anything regarding this article, please be sure to leave them in the comments below. Thanks for reading, and I hope you visit again soon!

6 thoughts on “Top 4 Reasons Why I Choose Debian vs Ubuntu Server”

  1. I got a free tier VPS with 0.5 GB RAM and that’s exactly what I have been looking for. At first I installed Ubuntu, but now I want to switch to Debian. But on big a server I’d prefer Ubuntu because I’m still a noob

  2. Daniel Planets

    Came here from a search for reasons why s.o. would choose ubuntu over debian for a server. You gave 2 reasons, and then a few against which may be summarized as: bloat.

    Me, I’ve gone through SuSE, ubuntu, debian, arch on the desktop and Slackware, SuSE, debian on servers. That’s from 1997 to 2022.
    On the desktop I want cutting edge and when Linus releases a new kernel and few days later I have that kernel running here, yep.
    On the server I want fast security updates (debian is great here) but otherwise: calmness. LTS, mature releases and few of them. Backports to the rescue when I really need a more current version of something.
    And, for basically everything I came around, there is always a repo or other install version for debian. Cause it’s Grande.
    Have to say though that there is a huge, rich, ample supply of community help pages for ubuntu and it happens again and again that I use those within debian and find them useful.

  3. I’ve found Debian to be leaner, cleaner, and meaner in my usage than Ubuntu. During the early days of COVID I had to turn an old laptop into a daily driver so I could work from home, and after trying CentOS and Ubuntu, I found that Debian had good performance, even with the GUI, and was way more stable than the others. It helped that the Unifi network application I had running my home LAN is certified to run on Debian, so I was able to port it over from a (very unstable) older Windows 10 PC.
    Once I was able to build myself a proper home PC (running Windows 10 Pro because I’m also a gamer ;), I set up a Debian VM in Hyper-V to take over from the old laptop. With 1 CPU and 2GB RAM (and no GUI this time) it runs brilliantly and with very little CPU usage on average.

  4. I got a Digitalocean droplet with Debian and 1 GB RAM. The memory usage when I just boot and SSH in is near 19% (as below). Why would it be so wide apart from your 7%? (I realize without more info you could only guess at the sort of things that could have made the difference.) Thank you.

    $ free
    total used free shared buff/cache available
    Mem: 983768 270512 144756 3640 719356 713256
    Swap: 0 0 0

    $ vmstat -a
    procs ———–memory———- —swap– —–io—- -system– ——cpu—–
    r b swpd free inact active si so bi bo in cs us sy id wa st
    1 0 0 144756 558508 182672 0 0 2 6 21 34 0 0 100 0 0

    1. My best guess would be because DigitalOcean’s image is not a minimal install whereas my examples are actual minimal installations. For example, at the very least, I know that DO’s image deploys their agent service that reports stats back to their control panel.

Leave a Comment

Your email address will not be published. Required fields are marked *

I accept the Privacy Policy


Scroll to Top