Python 3.14.5 Reverts the Incremental Garbage Collector After Production Memory Pressure Reports

Overview

The Python core team released Python 3.14.5 on May 10, 2026, and the headline change is not a new feature but the removal of one. The incremental cycle garbage collector that shipped in Python 3.14.0 through 3.14.4 has been reverted to the generational collector inherited from Python 3.13. Release manager Hugo van Kemenade described the change in the official release post, writing that the incremental GC “has been reverted back to the generational garbage collector from 3.13, due to a number of reports of significant memory pressure in production environments,” according to Python Insider.

The maintenance release carries around 154 bugfixes, build improvements and documentation changes since 3.14.4, the python.org download page records. The revert had been telegraphed in a release candidate, 3.14.5rc1, which van Kemenade published on May 4 with the same explanation and an originally planned final ship date of May 8 — two days earlier than the actual May 10 release, per the Python Insider RC1 announcement.

What We Know

The change itself

When Python 3.14 first shipped, the language’s What’s New document described the new collector this way: “The cycle garbage collector is now incremental. This means that maximum pause times are reduced by an order of magnitude or more for larger heaps.” The same document noted that the collector had moved from three generations to two — “young and old” — and that ordinary gc.collect() calls would invoke “the young generation and an increment of the old generation, instead of collecting one or more generations.”

The official documentation has since been updated to record the reversal. From Python 3.14.5 onwards, the docs state: “Python 3.14.0-3.14.4 shipped with a new incremental GC. However, due to a number of reports of significant memory pressure in production environments, it has been reverted back to the generational GC from 3.13. This is the GC now used in Python 3.14.5 and later,” the docs page confirms.

Why it was reverted

Van Kemenade opened the reversion thread on the Python Discourse on April 16, 2026, and listed three reasons for going back to the older collector rather than trying to fix the new one in place. “The old GC is a known quantity,” he wrote; the new incremental GC “didn’t go through the PEP process”; and it “was rolled back just before the final release of 3.13” before being reinstated in 3.14. He added that the team had “discussed this in the core team and with the Steering Council.”

The scale of the production regression is documented in the same thread. Core developer Neil Schemenauer benchmarked the incremental collector against the older generational one and reported, on the Python Discourse, that “process memory use can be dramatically higher (5x was the worst case I saw) and runtime is slower (more time spent in GC, longer total execution time).” In a separate measurement he noted that “Peak RSS size was 2.7x with incremental GC.”

A concrete user-side case study lined up with those numbers. Software consultant Adam Johnson described an out-of-memory crash while migrating a client’s Django project to Python 3.14 on a 512-megabyte Heroku dyno. Memory climbed from 527 megabytes to 1,033 megabytes during a migrate run, and a Memray profile showed that “more than 50% of the memory usage was allocated in ModelState.render(),” Django’s mechanism for materialising temporary model classes during migrations. The incremental collector, Johnson wrote, “cannot keep up with the migration process’s tendency to create many cyclical objects,” and his workaround was a migrate extension that calls gc.collect() after each migration. Johnson said “the core team is making the right call reverting it,” in his blog post.

The bug report that anchored the decision

The Python Insider post links to a single GitHub issue, #142516, as the document of record for the production complaints. GitHub user HenriBlacksmith filed it on December 10, 2025, after seeing a memory leak when upgrading from Python 3.13 to 3.14. “I already opened a bug on urllib3 for this issue, it looks that may application using MSAL for Python library (which relies on requests, which relies on urllib3, which relies on ssl) is leaking memory when being upgraded from Python 3.13 to Python 3.14,” the reporter wrote, on the cpython issue tracker. HenriBlacksmith pointed to ssl.SSLContext.load_verify_locations as the specific call where memory was accumulating.

Both 3.14 and 3.15 are affected

Van Kemenade’s revert plan covers both shipping series. “The plan for 3.14 and 3.15 is still as outlined in the first post: have just the old generational GC available, no build-time or run-time switches,” he wrote on the second page of the Discourse thread. He explained the decision to drop the dual-collector option as risk management: “I don’t want the increased risk and extra complexity of having two GCs and extra options at this stage, especially for 3.14.”

The German tech site igor’sLAB framed the move as “a corrective release for real operating conditions” rather than a feature update, observing that “a nice theoretical latency gain helps little if services consume more memory under real load than planned,” in its 3.14.5 write-up.

A separate thread is already exploring repairs

On April 23, 2026, core developer Tim Peters opened a follow-up thread titled “Improving incremental gc,” demonstrating one of the collector’s failure modes with a short cyclic-allocation test in which “Nothing is collected at 2000 iterations. And still not by 4000 iterations…Nothing at all gets collected until about the 20 thousandth iteration.” Schemenauer replied that “It should not take major surgery to make the incremental GC work better,” sketching a fix that would “trigger GC every 2000 net new objects, like the generational GC” and that would “size the increments…such that we effectively do a full collection often enough.”

Core developer Mark Shannon proposed a different direction in the same thread: a hybrid that would “Collect gen 0 + increment of gen 2,” arguing that “Adding the gen0 collection to the increment is trivial; it’s a three line change.” Sergey Miryanov noted that an early-return guard had already been added: “The incremental GC has early return since 3.14.1. Even if threshold0 reached, it can exit early and skip all processing,” the Discourse thread records.

What We Don’t Know

• Which Python version will reintroduce an incremental collector, if any. Van Kemenade has ruled out a return in 3.14 or 3.15. Whether a redesigned incremental GC will land in 3.16 — and whether it will go through a formal PEP, as the original did not — is the subject of the active “Improving incremental gc” thread, but no decision has been recorded.
• The total population of affected applications. The release announcement and the issue tracker reference reports plural but do not enumerate them. Issue #142516 surfaces an MSAL-for-Python regression rooted in the SSL module, and Johnson’s blog adds a Django case study, but the full set of production reports referenced by the core team is not public.
• Whether 3.14.5 changes other shipped behaviour beyond the GC. The release notes describe “around 154 bugfixes, build improvements and documentation changes,” per Python Insider, without enumerating them in the announcement itself. The detailed changelog lives in the standard CPython release artefacts.

Analysis

The revert is the second time Python’s incremental collector has been pulled. The same code was first attempted in Python 3.13 and rolled back before that release went stable, then re-landed in 3.14 — a sequence van Kemenade himself acknowledged when listing the reasons for going back to the generational GC, on the Discourse. His other listed reason, that the change “didn’t go through the PEP process,” is unusual for a feature with this much surface area. Python’s PEP track exists precisely so that load-bearing runtime changes are reviewed and stress-tested in public before they ship to the wider ecosystem, and the implication is that the same change re-routed through a PEP would have surfaced the 5x memory worst case before the regression reached production.

The practical takeaway for operators of Python 3.14 services is narrow but immediate. Anyone running 3.14.0 through 3.14.4 with long-lived processes that allocate many short-lived cyclic structures — Django’s migrate, HTTP client stacks that allocate SSL contexts per request, anything that resembles Johnson’s profile — has a defensible reason to upgrade to 3.14.5 quickly. The revert is the smallest patch surface that addresses the regression: same language, same standard library, the prior collector. For users on 3.14.4 who never noticed a problem, the upgrade is still recommended; 3.14.5 also carries roughly 154 other fixes, the python.org page lists.

The larger question, whether Python eventually adopts an incremental collector at all, is now back in design. The threads opened by Peters and Schemenauer suggest the core team still believes incremental collection is solvable for CPython — but on a slower schedule, with a clearer benchmark suite, and presumably with the PEP review the first attempt skipped.