Open Source and Vendor Support Windows Compared

Every date and rule here comes from the vendor's or project's own lifecycle page, checked in September 2026. Policies change, so treat the table as a map and confirm your exact version at the source, which each linked article cites. Two patterns stand out. Projects with no vendor (PostgreSQL, Prometheus, Airflow, OpenSearch) publish patches for a fixed window and offer no response time at all. Vendors publish a window that is usually shorter than the time enterprises keep a version in production: one year for Kong and Starburst, nine months for Grafana, two years for Splunk.

PostgreSQL gives the longest and most predictable window, five years per major version, and no contract. MongoDB and Elasticsearch both retire versions faster than most estates upgrade: MongoDB 6.0 and Elasticsearch 7.17 are already out of vendor support and still common in production. OpenSearch 1.x and the open-source Greenplum builds have no upstream at all now. ClickHouse supports only recent releases even under a paid agreement. MySQL 8.0 joined that list in April 2026, and Cassandra 3.x is unmaintained by its project.

Observability tools have the shortest windows of all, because they release fastest. Grafana ships a minor version every other month and supports each for nine months. Prometheus stops fixing a minor release after six weeks, and its LTS line accepts only high-severity security fixes. Splunk gives each version two years. The practical result is that the monitoring stack is often the least supported system in the estate, and it is the one you depend on during every other incident.

Airflow 2 reached end of life in April 2026, and the move to Airflow 3 is a real migration. Airbyte no longer sells a self-managed enterprise edition, so self-hosted users have community support only, and support also varies by connector. Starburst supports an LTS release for twelve months. Pentaho's window is tied to its next release, which makes it hard to plan around. WSO2 is the long-window exception, with a minimum of three years per version, but only for subscribers. Spark maintains a release branch for six months, Flink supports only its two newest minor releases, and Kubernetes patches a version for about a year.

Message brokers and caches follow the same pattern and have their own comparison. RabbitMQ patches only its newest release series, Kafka fixes roughly its last three releases, and Redis publishes end-of-life dates per version.

There are four honest options. Upgrade, if the application and change calendar allow it. Buy the vendor's extended support where one exists, accepting that it is limited and temporary. Put an independent support contract behind the version you actually run, covering incident response, mitigation and the upgrade plan. Or have the version you run patched.

That last one is newer than most teams realise, and it changes the conversation. OSSeva, AceMQ's extended support platform, backports CVE fixes to end-of-life versions of several technologies on this page: Redis 6.2.x and 7.0.x, PostgreSQL 11 to 13, Apache Kafka 2.8.x to 3.7.x, ActiveMQ Classic 5.15.x to 5.18.x, GemFire 9.x and 10.x with Apache Geode, Spring Boot 2.6.x and 2.7.x, Apache Tomcat 8.5 to 10.x, Node.js 14 to 20 and .NET. Patches are signed and delivered through the package infrastructure you already use, so the security deadline is separated from the upgrade deadline. Most estates end up combining this with an independent support contract: patched builds close the vulnerability gap, and the contract covers the 3am call.