DUE TO SPAM, SIGN-UP IS DISABLED. Goto Selfserve wiki signup and request an account.
Status
Motivation
The critical section in Airflow's scheduler uses an optimistic strategy: it fetches a batch of scheduled task instances from the database (up to max_tis_per_query), then filters them in Python against all concurrency limits:
- pool slots
max_active_tasks_per_dagmax_active_tis_per_dag,max_active_tis_per_dagrun- executor slots (exception as it's local to scheduler).
This works well enough for standard workloads. However, in large-scale deployments with thousands of tasks—often driven by dynamic task mapping—it causes starvation, where the scheduler fixates on tasks from one constrained group, discards most after checks, and queues far fewer than possible per cycle. The issue appears identically across every one of these limits. It was first noted with prioritized pools nearly full, starving lower-priority ones despite free slots (Issue 45636). Unknown User (xbis) highlighted the same with huge DAGs hitting max_active_tasks. (Mail discussion). The pattern repeats for symmetrically for other concurrency limits: instead of skipping to viable tasks, the scheduler loops over the same ineligible set.
Narrow fixes like PR 54103 tackle one limit but ignore the rest, and production environments differ widely—from DAG run floods to mapped task surges or complex priorities. Building all limits into the initial query has been tough, often infeasible in the current design. PR 53492 tried window functions and lateral joins for a full solution, but orthogonal limits (pools independent of DAG caps) led to poor SQL performance and unresolved edges. PR 55537 utilized pessimistic DB procedures, which looks promising as it solves the problem, but still needs thorough examination and community discussion. Rethinking the priorities in airflow seems to be the simplest method, not yet examined practically (no POC created), where dag-level priorities are introduced, while the current task-level priorities will become internal to each dagrun, this methodology relies on changing the task-creation method, creating only tasks we can run with all concurrency limits considered per dagrun, and simplifying the main scheduler loop, fetching only max_tis tasks once, and moving them to the executor, in a single iteration, as any task in the scheduled state, is guaranteed to be able to run without further checks (other than executor_slots ).
Large-scale reliability is the goal here. Dynamic mapping enables massive DAGs for per-item batching (one task per file or data pointer), so Airflow has to handle it without breaking. Community benchmarks on real heavy loads would help confirm solutions, and we need queuing that's truly resistant to starvation under any concurrency limit. This proposal aims to serve the updated summary of our research in improving the scheduler's throughput and eliminating starvation. As there's still uncertainty regarding the desired outcome, we present all the strategies we tried or thought of, and expect a fruitful discussion.
Terminology
Optimistic scheduling refers to planning based on the best-case scenario assumptions, or in other words, making a single simple query, and iterating over the results, choosing the tasks which can be scheduled from the tasks returned by the given query.
Pessimistic scheduling is based on the worst-case scenario assumptions, or in other words, performing an exhustive scan on all tasks untill we either run out of tasks to examine or until we get to the desired amount of tasks which can run.
Hybrid scheduling is a general term for an adaptive strategy that can behave like optimistic or pessimistic algorithm, depending on the actual workflow.
Task scheduling in this AIP refers to the process of enqueueing tasks (sending tasks to executor, making them run)
Considerations
What change do you propose to make?
Change the methodology in which the scheduler currently decides which tasks to run, allowing for an increased throughput of the scheduler and running more tasks with a wider variety of workflows without causing noisy neighbours during scheduling.
This will be done through changing the semantics of the priorities in Airflow, given that now they are not clearly defined, yet they are at the root cause of scheduler starvation or cluster slowness, as they decide the ordering of tasks to be looked at, which does not change dynamically, meaning that if we have long running tasks blocked by a concurrency limit (i.e max_active_tasks_per_dag), the slot will not be available for scheduling until it gets to run, meaning that even if we have all tasks which can run, we will not schedule max_tis tasks, rather at the best case scenario, the scheduler will only be able to schedule max_tis - 1 tasks.
The proposed change is to introduce dynamic priorities, meaning that priorities will be defined during querying, according to multiple factors, including the time since last examined and task urgency (how close are we to missing the sla) with some kind of obsolescence algorithm along with general heuristics to allow for better scheduling decisions, where we do not starve tasks which can run, while allowing higher priority tasks to run before lower priority ones.
This AIP is open for discussion, the chosen method might change when new ideas arrise, currently, the proposed solution is for priority semantics to change.
Why is it needed?
Large-scale Airflow deployments with dynamic task mapping—generating thousands of tasks per DAG—suffer severe scheduler starvation. The optimistic strategy fetches batches of tasks but discards most due to concurrency limits, queuing almost nothing per cycle while workers idle and tasks pile up in scheduled state indefinitely. This change ensures scalable, equitable queuing across all limits, avoiding partial fixes and enabling reliable performance at extreme volumes.
Integration With Deadline Alerts
With the new addition of deadline alerts, where the task callbacks are moved away from the dag-processor into a task of their own, meaning that they will now take up an executor slot and act just like any other task, and as part of this AIP, we need to allow the callbacks to run as quick as possible (or at least be able to configure the behaviour), and so we will need to, as part of the new priority algorithm, add some kind of configurable weight to those callbacks, where we can decide if they will be considered as higher priority tasks or lower priority tasks.
The callbacks are assumed to not rely or not subject to any concurrency limits (as with regular tasks), as soon as a query selects the callback, the callback will be guaranteed to be moved to the executor to prepare for running, simplifying the problem with the new addition, yet for this, we will need to be able to distinguish between callbacks and regular tasks, both from inside the database and from python.
Maintaining backwards compatibility
In order to maintain backwargs compatability, we are required to design an algorithm such that the user may opt-in to the new additions of the algorithm, meaning that we have to introduce some kind of "weights" which decide the influence of the given scheduling parameters (i.e urgency, time since last viewed etc) having the default set to 0 (other than the current priority_weight).
HITL Urgency - manual intervention
In some cases, we might want to be able to increase the priority of the task, as suddenly, it became urgent, this can be done quite simple with a boolean flag, where you can set it from the UI, and we guarantee that task instances with the boolean flag on are always looked at first, and do not get de prioritized.
How is the airflow scheduler different?
Many of the studied and optimized schedulers (along with the algorithms) mainly refer to schedulers with preemptive abilities, being able to preempt tasks as needed and let them run when resources are available, in airflow this is not the case, as airflow does not have the ability to preempt a task mid-run, and rather, has to wait for the task to completly finish.
This introduces challanges such as and edge cases which do not exist in other schedulers, in example, what happens when there are a lot of tasks running, and a high priority task occupying more than 1 pool slot (i.e 10) and it constantly gets postponed due to not having enough pool slots to run, this is an issue with the general optimistic approach, where if you cannot run any task, you ignore it, yet here, the effect might get magnified (if urgency is not a factor) where tasks constantly run not allowing the big task to run, a mitigation can be to move the task to a different pool, having other tasks not prevent the big task to run.
The variety of the airflow jobs makes the challenge even bigger, as we can have tasks that run for seconds, and tasks that run for days, and a given task may run for more or less time, depending on the amount of data, they type of the task and even from external changes (such as a slow k8s cluster, data unavailable and more).
Are there any downsides to this change?
There are strategy-specific downsides documented below. The overall effect should be positive for all users.
Which users are affected by the change?
- Large-scale deployments
- Deployments shared by several teams
- Power users - clients that heavily utilize concurrency limits and priority weights
How are users affected by the change? (e.g. DB upgrade required?)
A DB upgrade might be required, depending on the solution of choice.
- Single-limit pre-filtering:
- No db migration is needed.
- Window functions:
- 2 integer fields need to be added to the task_instance field, nullable and slowly inserted as tasks are created.
- SQL Procedures:
- Same as window functions.
- Priority Semantic Changes:
- Possibly adding a priority field to the dag and or dagrun table.
- Possibly adding a new table to collect heuristics about the tasks, such that they won't need to be computed every time during runtime.
Implementation Considerations
Priority Semantics Changes
A consensus within the community suggests that rethinking priorities is a viable option among the presented alternatives.
The approach where the semantics of priorities change, in order to allow for new prioritization algorithms, which will allow the scheduler to make better decisions, based on multiple parameters, without starving tasks.
Priority use cases
Real use cases must be considered before introducing a mechanism. While prioritizing individual tasks appears to bring a nice-to-have granularity, it should be asked whether this granularity has real use cases. Is there a reason we want to define a total order on all the tasks running in a cluster? Do we think about comparing priority of an email-sending task in one DAG to a data pipeline triggered in another one?
Some may think that priorities, if at all, should be defined on the DAG level. It follows from the notion of DAG being a single, irreducible workflow from the user's point of view.
Current task priorities are used opportunistically - they have impact just on the tasks that are eligible to run in one iteration. There's nothing that prevents a less-prioritized task to "sneak" into an executor slot just one cycle before the more prioritized one comes in. There are even some edge cases where a low-prioritized task "steals" slot of a more prioritized one.
A crucial fact to remember is:
Priorities in Airflow have an impact when a cluster has insufficient resources or when concurrency limits are reached.
This is true, because otherwise we would expect things to "run on time". Priorities are helpful when we don't have enough pool slots, or the scheduler is choking on too many tasks.
Difficulties with task-level priorities
Pessimistic scheduling
Current task-level priorities make it challenging to implement a AIP-100 Eliminate Scheduler Starvation On Concurrency Limits scheduling algorithm in Python code. If we assume:
(0) A large amount of tasks, i.e. too large to be fetched entirely into code in one iteration.
(0') We want to schedule exactly max_tis task instances in every scheduler cycle if available. If not, schedule every task whose concurrency limits allow them to run.
The problem is described in points:
(1) The goal is to get N of the most prioritized tasks whose concurrency limits are met.
(2) Due to high workflow variety, it's hard to maintain a consistent view of tasks that are eligible to be scheduled.
(3) From (0'), (1) and (2) it follows that in every iteration we have to build a view of all the tasks sorted by their priority, and validate for every task if it's eligible to run until max_tis tasks are found that can run.
(4) Doing (3) in code considering (0) means possibly multiple fetches from the DB and in-code iteration. RTT and memory-buffer allocations are factors that make it extremely slow (from benchmarks).
If these points are correct (subject to discussion), then we must change the behavior of task priorities or remove them altogether in order to achieve a pessimistic in-code scheduling.
Non-pessimistic scheduling
As purely optimistic scheduling with constant priorities leads to starvation and decreased throughput mostly because of priority weights and a lack of variety between scheduler iterations, to continue with non-pessimistic scheduling, we still must change the way priorities work.
Theoretical summary
| Strategy Type | Optimistic | Pessimistic | Hybrid |
|---|---|---|---|
| Problem | Constant priority weights lead to starvation due to dropped tasks and low variety between cycles. | Can't be done in Python code due to technical difficulty in processing large amounts of tasks stored in SQL. | |
| Known solutions | SQL stored procedures. | Change priorities mid-run, use task obsolescence or other heuristics that allow more variety for the scheduler choosing tasks to run. |
Rethinking Priorities
Due to the complications with introducing a pessimistic approach (mainly maintnance and readability constraints), and after a discussion in the community, we have decided to choose the option where we rethink and redefine the meanings of priorities, where we give a concrete definition to what priorities mean in airflow, including expected behaviour examples, while mixing the definition with an aging algorithm (along with possibly other heuristics), this is a major semantic change to priorities which now, just means that a higher priority task will be considered more often than a lower priority one, while giving lower priority tasks preference while they get older (looked at less often).
Deciding first on what priorities will define is a first step before we can move on to the implementation, while the aging algorithm can be implemented either way, regardless of the chosen semantic for priorities.
Choosing the priority definition is a crucial part of the solution, and there are a few proposed strategies, arranged by the behavioral change they introduce, least to most.
Proposed Priority Strategies
As we approached on a solution, we decided to move on with changing the priorities in airflow, we have a few possible strategies, each with their upsides and downsides.
In order to decide on the proposed solution, we need the community to help decide on the strategy of choice.
The strategies listed bellow are (from best approach to worst):
Keeping task-level priorities but making them weaker
Introducing DAG-level priorities, changing task-level priorities
Introducing DAG-level priorities, giving up task-level priorities
Completely Removing All Priorities At All Levels
Keeping task-level priorities but making them weaker
Retain task-level priority weights, but make them flexible to avoid starvation.
Use last_scheduling_decision field of a task or a DAG and apply a mid-run "weight rule" that changes task priorities based on obsolescence heuristic.
Mitigate starvation by using round-robin style scheduling where the priority of the tasks determine the order in which dagruns will be looked at.
An example is taking the highest priority task (awaiting scheduling) of each dag, and multiplying the priority by the delta since the dagrun was considered.
This is a classic solution against starving less-prioritized tasks - punish tasks that couldn't be scheduled for too long.
This causes the least api-breakage for users, while providing a good solution to starvation.
Though it is harder to implement, requires SQL queries to calculate the priorities mid-run.
Adds even more to opportunistic nature of priorities and draws us away from the original use-case - DAGs with long but important tasks can be deprioritized at critical moments though it can be solved with an urgency factor.
Starvation is mitigated, but the algorithm still remains optimistic - meaning some time may be needed to adjust for starved, highly-prioritized tasks and move forward.
Can remain fully backwards compatible with no breakage, by setting weights to a value of 0, meaning that only the task priority is looked at.
Though, even with all of that,to avoid deprioritizing important tasks, the user will be able to define a policy that controls how quickly we're going to allow such deprioritization.
The logic change matches the opportunistic nature of task priorities that become even more opportunistic. You apparently can't rely much on priority weights anymore, but you couldn't rely on them before either.
Conclusion
No API breakage, though logic still changes considerably. Imposes higher maintenance burden and more implementation complexity, yet mitigates starvation in a classic way of punishing long-awaiting tasks.
Introducing DAG-level priorities, changing task-level priorities
Introduce DAG-level priorities, where each DAG run created inherits the priority of the DAG it belongs to.
DAG-level priority acts as a global priority deciding which DAGs will be looked at first.
Task-level priority acts as an inter-dagrun prioritization, where tasks of the same dagrun are considered in order of the priority of the given tasks
Use heuristics to punish DAG runs whose tasks couldn't be scheduled for too long.
This stems from a use case of prioritizing entire workflows. Classic solution against starving less-prioritized DAGs - punish DAGs that couldn't be scheduled for too long.
While also adding more control over the ordering in which tasks are considered, giving the user fine-grained priority control.
This allows us to accurately match the workflow model of Airflow, starvation is mitigated by deprioritizing DAG runs that waited for too long. Meets well the prioritization use case.
This is not without drawbacks, behavioral API breakage is added (long-existing feature changed). Unexpected reliance on task-level priorities may change the execution of users' workflows.
Adds even more to opportunistic nature of priorities and draws us away from the original use-case - DAGs with long but important tasks can be deprioritized at critical moments (depending on the algorithm of choice).
Starvation is mitigated, but the algorithm still remains optimistic - meaning some time may be needed to adjust for starved, highly-prioritized tasks and move forward.
Though to solve this, we implement solutions from the previous idea as well of keeping the priorities without adding new priorities and to avoid deprioritizing important DAGs, the user will be able to define a policy that controls how quickly we're going to allow such deprioritization.
Conclusion
API breakage is minimal, though logic still changes considerably. Imposes higher maintenance burden and more implementation complexity, yet mitigates starvation in a classic way of punishing long-awaiting tasks.
Introducing DAG-level priorities, giving up task-level priorities
The approach suggests to introduce DAG-level priorities, where each DAG run created inherits the priority of the DAG it belongs to.
DAG-level priority acts as a global priority deciding which DAGs will be looked at first. To retain optimistic scheduling and prevent starvation at the same time, as in the strategy on the left, a notion of obsolescence is needed.
Task level priorities are ignored and not taken into account while performing scheduling decisions, and are kept solely for backwards compatibility.
The approach stems from a use case of prioritizing entire workflows. Classic solution against starving less-prioritized DAGs - punish DAGs that couldn't be scheduled for too long, just as before.
Accurately matches the workflow model of Airflow, starvation is mitigated by deprioritizing DAG runs that waited for too long. Meets well the prioritization use case.
Behavioral API breakage is introduced (long-existing feature removed). Unexpected reliance on task-level priorities may break the execution of users' workflows.
It adds even more to opportunistic nature of priorities and draws us away from the original use-case - DAGs with long but important tasks can be deprioritized at critical moments (depending on the algorithm of choice).
Starvation is mitigated, but the algorithm still remains optimistic - meaning some time may be needed to adjust for starved, highly-prioritized tasks and move forward.
just like the previous strategy proposed, to avoid deprioritizing important DAGs, the user will be able to define a policy that controls how quickly we're going to allow such deprioritization.
Conclusion
The approach that matches the use case of prioritizing important workflows in conditions of resource deficit, makes priorities more comprehensive and easier to control for the end user despite giving up some granularity. Imposes some Behavioral API breakage, as task-level priorities won't do anything anymore.
Completely removing all priorities at all levels
Suggests to remove all priorities, use plain round-robin scheduling by last_scheduling_decision of the DAG run.
Check only the concurrency limits, and create tasks without looking or caring about ordering.
This approach is plain and simple, easy to implement and does not induce any complexity, leaving the priority_weight without actually using it retains backwards compatibility.
The issue with the given approach is that API breakage is introduced (long-existing feature removed). Unexpected reliance on task-level priorities may change or break users' workflows.
The use case of prioritizing on low resources is not met which requires users to carefully adjust workflow to existing CPU power, risking important tasks stalling.
A decision can be made that running Airflow on insufficient resources is an inherent problem not addressed by the project.
Conclusion
Simplest implementation and maintenance, yet removes a widely used feature. Makes scheduling the simplest job possible. The use case of prioritizing on low resources is not met.
API breakage in the long run, the priority_weight field will just be a placeholder in the task until it is removed.
Migration
A major change such as refactoring priority weights requires a careful consideration for possible breakages and user migrations. As it's hard to know how people use priority weights, there is a need for a community brainstorm regarding possible breakages and how we can mitigate them.
A hybrid approach where task-level priority weights are retained is the easiest one to handle, as a toggle for enabling the hybrid approach may be added. For example, the obsolescence algorithm may be turned on/off or tuned with user-specified policy, see Separation of mechanism and policy.
Theoretically, every approach taken may be enabled or disabled with a toggle for several releases, allowing users to tests their workflows with the new strategy (in case task-level priority weights are removed).
Proposed Obsolescence Algorithms
Obsolescence Algorithm
Implementing any change in the priority semantics still leaves place for starvation, where same prioritized dagruns are considered over and over, without considering other lower-priority dagrun's tasks, even if we can run the given tasks, and so in this case, an obsolescence algorithm comes into play.
Having an obsolescence algorithm means that even if there are more prioritized dagruns, their relative priority changes, as we take into a count the time since last scheduling descision on the current dagruns, meaning that the older the dagrun, the higher priority it will be, while a higher priority dagrun which is old, will still be looked at before a lesser prioritized dagrun waiting for the same amount of time.
This introduces the complication of choosing the obsolescence algorithm, such that it remains simple, easy to implement and understand while still allowing for round-robin style prioritizd scheduling.
As part of the algorithm, we might also look into dag defined sla's, and prioritize dags with a closer sla, in addition to all the aging part, where we also consider last_scheduling_decision minus the current time.
A few algorithms emerge, that allow the scheduler to make smarter decisions, and ensuring that tasks do not starve, in order, from simplest to most complex.
| Algorithm | Simple Weighted Aging | Improved Weighted Aging | Weighted Aging and SLA Urgency |
|---|---|---|---|
| Motivation and Explanation | The simplest algorithm, which will work for most cases. To get the runtime priority of a workflow, take the defined priority of the workflow, apply a simple arithmetic operation (such as multiply the values), and order by the result. This allows for higher priority tasks to be looked at more often, though can cause issues when a priority is to high. The choice of the arithmetic operation can vary the behaviour drasticly, from giving the priority more effect on the scheduling decisions or less. | An approach similar to the simple weighted aging aproach, yet the choice of the aging algorithm is a smarter algorithm allowing for complex scheduling behavior with simple logic, where no workflow types are left to starve. This is a promising choice, as it is both simple and effective at solving the issue, yet it will most likely lack tunability, as there will most likely be only 1 or 2 variables to tune, which will change either the weight of the priority or the weight of the waiting time. | A weighted aging algorithm with urgency of tasks, which is needed to solve the "starvation of highly prioritized tasks in critical moments", where we consider the sla urgency of a given dag along with the priority, this allows for a complete optimistic solution for task scheduling while significantly mitigating starvation across the workflows. This is the more complex solution, yet this solution is the one which solves all of our issues, and can be extended to various directions, with countless improvements which can be built uppon the given solution. Possibly add the average dagrun or task runtime to the urgency heuristic to make more accurate predictions, yet it might introduce more complexity than the potential performance gain. All while allowing for inter-dagrun priorities with the current A proposed aging algorithm is shown below. score (J, t) =Pbase×Wp + Wh * (waiting_time + service_time) / service_time + Wu * (1/(deadline - current_time - service_time)) Pbase - base priority of a Job waiting_time - time since task was scheduled / last examined score - runtime priority |
Advantages |
|
|
|
Drawbacks |
|
|
|
| Summary | The simplest of the bunch, yet might not fully solve all issues for all possible scenarios. | An improved alternative to the simple weighted aging, fitting a wider spectrum of workflows, while not hindering implementation complexity. | The most complex behavior-wise yet solves the widest variety of use cases, allowing for tunability and behavioral control. Not more complex than any of the other proposals, while solving starvation of tasks in a relatively optimistic manner. |
In order to be able to have a HITL intervention of the priority, we may add a bool field to the task_instance table (nullable) where if set to true, it gets sorted at the top always, can be easily done by having it first in the sorting order before the algorithm itself.
What defines this AIP as "done"?
The Airflow scheduler's performance improves in terms of queued tasks over a time frame. Any unnecessary starvation is eliminated after improving the algorithm of the task queueing logic.
Appendix
Other non aging algorithms
Other non aging algorithms can and should also be considered, as they may spark a new idea for discussion which solves starvation.
Priority bands
One of the first algorithms that came to mind during research was a priority band algorithm, meaning that we take the current tasks which can run, divide them into priority bands (configurable by the user) and give each priority band an amount of slots, from which we always select that amount (if possible) before moving to the next priority band, meaning that if we have 3 priority bands, the highest priority band gets 50% of the slots, and the ones after it get 30% and 20% accordingly, this allows for lower priority tasks to be still included (as the highest priority does not indefinitly starve lower priority tasks) yet in this case it is still possible to get starvation when no tasks can be run from each priority band (yet it is highly mitigated), and so here, it is also preferable to add some kind of aging algorithm in order to eliminate starvation.
This approach is promising, yet it means that during deployment we will have to define the priority bands ourselves, and the shares for each priority band.
Credit/Quota system
Similar to priority bands, instead of selecting a percentage from each priority band, we assign each priority band a "quota", where we always select the most prioritized tasks from each highest priority band, and when we successfuly run a workload from a priority band, we decrement the credit count, if no credits from the top priority band were found, we schedule the next priority band, and refill the credits when the count reaches 0, this means that even if we have a lot of prioritized workflows, eventually, their credits will run out, and there will be credits for the lower priority jobs, as if we have 0 credits, for the given scheduling loop, we do not select anything from that priority band, and in the end we refresh the count.
This solves starvation on average as well, yet still needs to be configured before the system starts, and it also is not adaptive, meaning that scheduler throughput may go down.
Lottery scheduling / Stride scheduling
Unlike the priority and systems above, this does not require any configuration before the system is started, instead, each task has a priority, the priority accounts for the ammount of "tickets" that it has, when it comes time to schedule the workflows, we draw N unique tickets from the ticket pool that we have (all the tasks), and the drawn tasks, are the one's that get to run, yet this method is not deterministic, and so we can also utilize the deterministic version of the lottery scheduling, called Stride scheduling, yet it needs to be addapted to the non-preemptive nature of airflow, where we cannot increase the pass for a running task, and so we need to have the pass refresh every day or week, yet this means that tasks which are rarer will have a higher priority untill the pass resets, and so might be a better idea to stick with lottery scheduling.
It is also possible to add a weight to the priority, and even have some kind of function for deciding the amount of tickets by priority, yet this will not be deterministic.
Strict wait time / deadline scheduling
In this approach, we schedule normally by priority, but if a task is close to it's deadline, it instantly becomes the highest prioritized task, meaning that it will be examined the most, it is also possible to make it such that no other tasks are scheduled while there are tasks that are close to their priority, so that resources will be cleared, yet this is not a great solution, as it does not really solve starvation, only tries to mitigate it in the most prititive way which might not work and make starvation worse.
Alternatives considered
| Strategy | Current optimistic | Single-limit pre-filtering | Window functions | SQL procedures / exhaustive linear scan | Priority Semantics Changes |
| Description | Fetch up to | Use a single limit, like max_active_tasks and eliminate starvation on that limit using lateral join / window function. | Nested window functions/lateral joins incorporate multiple limits in a single query. | DB-stored procedures (PostgreSQL/MySQL) or Python (SQlite) scan sorted TIs exhaustively until enough queueable ones found. | Increase the scheduler's variety of choice by giving up the concept of task-level priorities. |
| Motivation | Simple, fast for small/medium workloads; no complex SQL. | Improves performance by considering just one most common concurrency limit which works for many users. | Theoretically, could allow checking multiple concurrency limits in a single SQL query. | Universal solution for all orthogonal limits; eliminates post-fetch drops entirely. Runs on DB side and prevents RTT latencies / slow Python processing. | Priorities make it very hard to come up with a viable in-code solution as every single task should be considered in each iteration. Allowing for a change in the priorities defenition (which as of now is not clearly defined) will allow us to consider tasks in a simple manner without causing a maintnance overhead while solving starvation |
| Advantages | Minimal query overhead; works across DBs including SQLite; easy to maintain/debug, as most logic is in Python. | Boosts throughput for large DAGs (hundreds of tasks); avoids wasting cycles re-querying saturated DAGs. | Theoretically comprehensive, single query for all DB vendors. | Throughput gain even with multiple limits, fewest scheduler iterations, blazingly-fast linear scanning. Solves all starvation cases by using a simple and algorithmically efficient scan on DB side where the data resides. | Per-task priorities are incomprehensible and significantly complicate scheduling. Directly removing any scheduling strategy relying on obsolescence, meaning round-robin style scheduling is not possible. Using an obsolescence based priority algorithm allows for a clearly defined priority behaviour, while keeping scheduling descisions effiecient and fair. |
| Drawbacks | Throughput degradation that leads to starvation in case the average number of schedulable tasks per query is low across iterations. | Considers just one limit and solves just part of the problem, while some limits continue to starve. For example, while max_active_tasks is handled in the query, pool limits may cause tasks to be dropped. | Window functions' behavior is not suitable for Airflow task concurrency model, and they don't solve all cases while imposing a large performance overhead. | Requires several implementations for different DB vendors, may be considered a technical debt. The logic is difficult to test. SQLite doesn't support procedures at all. | Requires a complete refactor of priority logic which is a breaking change. Breakage in the current expected behaviour, may have an effect on existing workflows. Defining a good obsolescence scheduling heuristic can be hard and tedious, as it requires trial and error. |
| Drawback mitigations | Deploy multiple Airflow clusters for large workloads. | It solves the common case of DAG run level limit. Don't define complex concurrency constraints in workloads. | Cases where tasks are dropped with this approach are rare. | DB vendors are not added too often, as critical section algorithm isn't frequently updated, if at all. If it is, adding the logic in several places isn't a big overhead. Keep the logic as simple as possible so no testing is needed. Mimic the algorithm in Python for SQLite. | The change is beneficial to the project as it both contributes to solving starvation and provides a more useful priority feature, while allowing to control which workflows are more important than the others, without starving other workflows. |
| Summary | Serves typical workloads well but fundamentally incapable of handling large-scale starvation without repeated post-fetch drops. | Helpful short-term throughput boost for one common limit, but can't be a long-term solution since other concurrency limits like pools and max_active_tis_per_dag/dagrun remain frequently used and broken. | Theoretically elegant but ruled out—unsuitable for Airflow's multi-dimensional concurrency model and imposes a slight performance overhead (up to 10x slower on large tables). | A viable path forward; benchmarks show 1.7-2x throughput gains across single/dual/triple limit workloads. Remaining technical issues (metrics, SQLite, DB fields) are resolvable, drawback mitigation is possible. | Promising alternative if community reaches consensus on desired priority semantics; enables simpler in-code round-robin scheduling by reducing per-task priority complexity. |
| POC | Runs in production | PR 54103 | PR 53492 | PR 55537 | Still to come, may be several POCs depending on the number of implementations |