Comparing a control barrier function with model predictive control is not a comparison of two controllers. It is a comparison of two promises. A CBF certifies that a set is forward invariant, meaning the state never leaves it, for all future time, evaluated at the state you are in right now. An MPC minimises a cost subject to constraints over a finite horizon, applies the first input of the plan it just computed, and then computes a new plan. One is a certificate. The other is a plan.
Almost everything written about control barrier functions versus model predictive control is a research paper proposing a way to merge them. Those papers are good and this article cites several of them. But a paper that unifies the two answers a question you did not ask if what you actually have to do is decide what to build this quarter. So here is the comparison stated as a decision: what each one guarantees, the failure each one owns, what each one costs per control step, and how the choice changes when the plant is slow.
What MPC gives you that a barrier filter does not
Prediction, and the willingness to spend it.
The MPC-CBF paper from Berkeley puts the difference in one sentence in its own motivation. CBF formulations use only current state information, without prediction, which yields a greedy control policy. Model predictive control gives a less greedy policy because it takes future state information into account. That is the whole case for MPC in a nutshell, and it is a real case.
The second thing MPC gives you is that everything lives in one optimisation. Tracking error, actuator limits, rate limits, an economic term, a soft comfort constraint: all of it is written into the same problem and traded against the others by the solver rather than by you. Ugo Rosolia's exposition of the method describes the structure plainly. The controller solves over a horizon N much shorter than the task duration, and uses a terminal cost and a terminal constraint set to approximate cost and constraints from the end of the horizon out to completion of the task.
Hold on to that last clause. The terminal components are where MPC's safety problem lives.
What a barrier filter gives you that MPC does not
A guarantee that does not expire, and a component rather than a controller.
The CBF condition, when it holds, implies forward invariance of the safe set for all future time. Not for N steps, not until the plan is recomputed. The mechanics of that condition, what h(x) is, why the class K function makes it minimally restrictive, and why it reduces to a quadratic program for control-affine systems, are the subject of what a control barrier function actually certifies and are not re-derived here.
The property that matters for this comparison is architectural. The guarantee attaches to the set and the dynamics, not to whatever proposed the action. So the filter wraps a PID loop, an operator setpoint, an MPC or a learned policy without any of them being modified, which is why the standard deployment is installing the filter around a policy you already have. An MPC is not a component. It replaces your controller.
The failure each method owns
Both methods work. Each has one characteristic way of failing that the other does not have, and picking between them is mostly picking which failure you can live with.
MPC: safety beyond the horizon
An MPC is safe over its horizon and says nothing about what happens after it. In theory the fix is known: a control invariant terminal set, or a horizon long enough that the terminal constraint is satisfied anyway. In practice, work on sampling-based MPC with learned barrier functions reports that safety beyond the prediction horizon is often overlooked by practitioners, potentially leading to violations at future timesteps, and that the theoretical techniques are difficult to apply and thus rarely used, especially in the case of general nonlinear dynamics.
Rosolia's exposition supplies the mechanism and the reason the fix is hard. With a short horizon the controller takes shortsighted actions: in autonomous racing, a predictive controller that plans without accounting for an upcoming curve may accelerate to the point that safe turning is infeasible. The remedy is a terminal set that is control invariant, so that a feasible input always exists at the end of the plan. Then comes the concession that decides the argument. Computing the maximal stabilisable set and the optimal cost function is as complex as solving the original control problem.
The theoretical fix for MPC's safety gap is, for a nonlinear plant, roughly as expensive as the problem you were avoiding by using MPC.
CBF: myopia and conservatism
The barrier side has two distinct weaknesses that get conflated under the word conservative, and it is worth separating them because they have different remedies.
The first is the policy. It is pointwise: the best admissible action now, with no account of where the trajectory goes next. Berkeley calls it greedy, the tutorial literature calls it myopic, and it is the same property. The NSF summary of the MPCBF line of work states the trade in one line, that a CBF offers a conservative policy while traditional MPC lacks the safety guarantee beyond the finite horizon.
The second is the certificate itself. The Oxford work on predictive control barrier functions is direct about it: a CBF identifies a potentially conservative invariant subset of the safe set, and current methods usually yield overly conservative CBFs. Constructing the maximal one exactly means reachability analysis, which is well known to suffer the curse of dimensionality. So you are not usually certifying the region you care about. You are certifying an inner approximation of it, whose tightness you rarely know.
Same paper, one more observation worth carrying into any design review: unsafe control actions may not immediately violate state constraints, yet can nevertheless inevitably reach unsafe regions. That is the entire reason invariance is the property being certified rather than constraint satisfaction at each instant.
The symmetry is clean. MPC's guarantee is bounded in time. The CBF's guarantee is bounded in performance.
The comparison that usually settles it: cost per control step
Here is the axis the papers treat as an implementation detail and engineers treat as the specification.
A CBF filter is one small quadratic program per control step, sized by the number of inputs and active constraints. An MPC is an optimisation over the whole horizon, every step. Berkeley notes the consequence when discussing the alternative fix for MPC's late-binding distance constraints, which is simply to use a larger horizon: that will increase the computational complexity in the optimization.
Read the two failure modes together with that line and the shape of the problem appears. MPC's safety gap closes as the horizon grows. The cost of the horizon grows with it. The remedy and the constraint are the same variable.
Numbers from our own control stack show what that budget looks like once it is real. The safety layer answers in under 2 ms. The end-to-end edge path is 285 ms, reduced from 1.2 seconds. Two orders of magnitude between the filter and the thing it guards, and that ratio is the specification rather than an accident of implementation: a safety layer that queues behind a late policy cannot overrule it. Getting the 285 ms itself was a separate discipline, a matter of compressing the model until it fits the budget.
If your control period leaves room for a horizon-length nonlinear solve, MPC is on the table. If it leaves room for a small QP, the barrier filter is on the table and the MPC is not, whatever its theoretical advantages.
What the research actually converged on
The honest answer to which is better is that the field mostly stopped choosing, and it is worth knowing what the combinations look like before deciding you have to pick.
Berkeley's MPC-CBF puts discrete-time CBF constraints inside the MPC. The motivating observation is specific: safety in a predictive framework is usually written as a Euclidean distance constraint, and such a constraint does not confine the optimisation until the reachable set along the horizon intersects the obstacle. In other words the robot does not act until it is already close. A barrier constraint binds earlier, which is how the method gets safe behaviour without buying a longer horizon. They verify it on a 2D double integrator for obstacle avoidance and on a competitive car racing example where the ego car overtakes.
Cosner, Bena and Ames study the same union from the robustness side and frame both methods identically, as seeking to enforce safety constraints while minimally deviating from a performance objective. They report that the combined MPC+DCBF controller displays favourable safety, performance and closed-loop feasibility properties, in nominal operation, under bounded uncertainty and under stochastic and potentially unbounded uncertainty, and they demonstrate it on quadrupedal and quadrotor robots doing dynamic obstacle avoidance rather than in simulation alone.
The MPCBF work approaches it from the other end, constructing CBF invariant sets with sum-of-squares methods and using them as the terminal constraint on the last predicted state, which is exactly the control invariant terminal set the theory asked for, and which buys a shortened horizon.
And the Oxford paper explains why any of this composes at all: the value function of a suitably formulated safe MPC is itself a control barrier function, in the same way that traditional MPC value functions act as control Lyapunov functions for stability. The two methods are not rivals with a shared application area. They are two constructions of the same object from opposite directions.
One caveat before you adopt one. These are research formulations. Adding a barrier filter to a controller you already run is an integration task. Adopting MPC-CBF or MPCBF is building a new controller and owning its solver, its feasibility behaviour and its tuning.
Choosing on a slow industrial or biological process
Nearly all of the above was validated on quadrotors, quadrupeds and racing cars: fast, well instrumented, cheap to reset. If your plant is a reactor, a gasifier or a cultivation basin, three things move the answer.
The horizon is cheap in time and expensive in model error. A 20-step prediction on a bioprocess is 20 compounding steps of a model fitted to sparse, irregular measurements. On a slow plant you have the wall-clock budget to compute it, which tempts you into it, and the prediction is worth less than the same computation on a quadrotor because the model underneath it is weaker. If you go that route, the model is the project, which is the argument for continuous-time models fitted to irregular sampling rather than a discrete one-step-ahead fit stretched across a horizon.
The state is inferred, not measured. Neither method escapes this. An MPC propagates estimation error forward through the horizon; a barrier function evaluates h on the same estimate. It is not a reason to prefer one, but it is a reason to distrust any comparison imported unmodified from robotics, and it is why the validation question is really a question about sim-to-real transfer.
Myopia costs less when the physics is slow. The greedy action is punished over minutes rather than milliseconds, and the filter re-solves thousands of times before the consequence arrives. The CBF's central weakness is partly a function of timescale, and on a slow plant the timescale is working for you.
Our own stack reflects that ordering. The barrier layer sits above the learned policy, not inside a predictive optimisation, and the record is a 500 L pilot basin with zero safety violations across 400 simulated years, with growth-model accuracy at R-squared above 0.95. Those simulated years should be read as what they are, coverage of the state space rather than elapsed operating time.
A decision procedure rather than a verdict
Five questions, in order.
Is the property you need invariance or optimality? If you have to prove that something never happens, you need a certificate, and an MPC does not produce one past its horizon. If you need the best trajectory under competing objectives, that is what MPC is for.
Can you write the safe set as a function of state in physical units? If not, there is nothing to certify yet and the CBF branch is closed until there is.
Does your control period fit a horizon-length solve? Not on a workstation. On the hardware at the plant, at the rate the process runs.
How far ahead does the plant punish a greedy action? Milliseconds argues for prediction. Minutes argues that a pointwise filter re-solving continuously will catch it.
Is the thing proposing the action trustworthy or learned? If it is learned, the filter is not optional whatever else you decide, and the assumptions that guarantee rests on become the load-bearing part of the design. The full build order for that case is what has to be proven before a learned policy moves a valve, and the broader question of whether a learned policy beats the predictive baseline at all is reinforcement learning against MPC for process control.
Derive the equations first. Then decide what is allowed to act on them, and for how long you are willing to promise it.
FAQ
Is MPC safe by itself?
Inside its horizon and its constraint set, yes. Outside the horizon it makes no claim, and the terminal components that would extend the claim are the difficult part of the design. The sampling-based MPC literature reports that safety beyond the prediction horizon is often overlooked by practitioners and can lead to violations at future timesteps, and that the standard remedies are difficult to apply and therefore rarely used for general nonlinear dynamics.
Which is more computationally expensive?
MPC, structurally, because it optimises over a horizon rather than a single step, and because lengthening the horizon to improve safety increases complexity further. A barrier filter is one small QP per step. On constrained plant hardware this is usually the axis that decides the question before any of the theoretical arguments get a hearing.
Can a control barrier function be used inside an MPC rather than around it?
Yes, and that is the dominant research direction. Discrete-time CBF constraints can be imposed on the predicted states inside the optimisation, which makes the safety constraint bind early instead of waiting for the reachable set to touch the obstacle. A CBF invariant set can also serve as the MPC's terminal constraint, which is one of the few tractable ways to build the control invariant terminal set the stability theory asks for.
Does a longer horizon remove the need for a barrier function?
In theory a sufficiently long horizon, or a control invariant terminal set, does the job. In practice both are hard: computing the maximal stabilisable set and the optimal cost function is as complex as solving the original control problem, and horizon length is capped by the control period. The gap between the theoretical fix and the affordable one is why barrier constraints keep being added to predictive controllers.
Which one should I use for a bioreactor or a similar slow process?
The literature does not answer this, because it was written on fast robotic platforms, so treat this as reasoning rather than citation. Slow dynamics reduce the cost of a pointwise policy, weak identification raises the cost of a long prediction, and inferred state degrades both. That combination tends to favour a certified filter over a predictive controller as the first thing to build, with prediction added later once the model is good enough to justify the horizon.