> As much as I love FreeBSD, the release schedule is a real challenge in production: each point release is only supported for about three months.
I think point releases "don't count". Point releases means you run freebsd-update, restart and are done.
And major releases tend to be trivial too. You run freebsd-update, follow instructions it puts out, do `pkg update -u`.
Been doing that for production database clusters (Postgres) for hundreds of thousands of users for over a decade now and even longer in other settings.
Sure you do your planning and testing, but you better do that for your production DB. ;)
These are thousands of queries a second setup including a smaller portion of longer queries (GIS using PostGIS).
That said: Backwards compatibility is something that is frequently misunderstood in FreeBSD. Eg. the FreeBSD kernel has those COMPAT_$MAJORVERSION in there by default for compatibility. So you usually end up being fine where it matters.
But also keep in mind that you usually have a really really long time to move between major releases - the time between a new major release and the last minor release losing support.
And to come back to the Postgres Setup. I can do this without doing both the DB (+PostGIS) upgrade at once cause I have my build server building exactly the same version for both versions. No weird "I upgrade the kernel, the OS, the compiler and everything at once". I actually did moved a from FreeBSD 13 to 14 and PG from 14 to 18 - again with PostGIS which tends to make this really messy on many systems - without any issues whatsoever. Just using pg_upgrade and having the old versions packages in a temporary directory.
This is just one anecdote, but it's a real life production setup with many paying customers.
I also have experience with RedHat, but for RedHat the long term support always ends up being "I hope I don't work here anymore when we eventually do have to upgrade".
But keep in mind we talk about years for something that on FreeBSD tends to be really trivial compared to RedHat which while supporting old stuff for very long does mean a lot of moving parts, because the applications you run are a lot more tied to your release.
On FreeBSD on your old major release you totally can run eg the latest Postgres, or nginx, or python or node.js or...
I think point releases "don't count". Point releases means you run freebsd-update, restart and are done.
And major releases tend to be trivial too. You run freebsd-update, follow instructions it puts out, do `pkg update -u`.
Been doing that for production database clusters (Postgres) for hundreds of thousands of users for over a decade now and even longer in other settings.
Sure you do your planning and testing, but you better do that for your production DB. ;)
These are thousands of queries a second setup including a smaller portion of longer queries (GIS using PostGIS).
That said: Backwards compatibility is something that is frequently misunderstood in FreeBSD. Eg. the FreeBSD kernel has those COMPAT_$MAJORVERSION in there by default for compatibility. So you usually end up being fine where it matters.
But also keep in mind that you usually have a really really long time to move between major releases - the time between a new major release and the last minor release losing support.
And to come back to the Postgres Setup. I can do this without doing both the DB (+PostGIS) upgrade at once cause I have my build server building exactly the same version for both versions. No weird "I upgrade the kernel, the OS, the compiler and everything at once". I actually did moved a from FreeBSD 13 to 14 and PG from 14 to 18 - again with PostGIS which tends to make this really messy on many systems - without any issues whatsoever. Just using pg_upgrade and having the old versions packages in a temporary directory.
This is just one anecdote, but it's a real life production setup with many paying customers.
I also have experience with RedHat, but for RedHat the long term support always ends up being "I hope I don't work here anymore when we eventually do have to upgrade".
But keep in mind we talk about years for something that on FreeBSD tends to be really trivial compared to RedHat which while supporting old stuff for very long does mean a lot of moving parts, because the applications you run are a lot more tied to your release.
On FreeBSD on your old major release you totally can run eg the latest Postgres, or nginx, or python or node.js or...