Velocity vs. BungeeCord vs. Waterfall: Choosing a Proxy
All three connect multiple backend servers behind one address. Which one actually makes sense depends on how current the rest of the network's software stack is.
Velocity vs. BungeeCord vs. Waterfall: Choosing a Proxy
Three different proxies solving the same basic problem — one address, multiple backend servers — at different points in their development lifecycle.
BungeeCord
The original Minecraft proxy, built by the Spigot team, and the one most older guides and plugins reference by default. Still functional, but development has slowed considerably compared to its earlier years, and it generally lags behind in supporting newer Minecraft protocol features and performance improvements.
Waterfall
A fork of BungeeCord built by PaperMC, created specifically to improve on BungeeCord's performance and fix long-standing bugs while maintaining compatibility with existing BungeeCord plugins. For a while, Waterfall was the natural upgrade path for anyone running BungeeCord.
Velocity
Also built by PaperMC, but written from scratch rather than forked from BungeeCord — a modern proxy with substantially better performance, built-in support for modern forwarding (more secure than BungeeCord's legacy forwarding method), and active ongoing development. Velocity doesn't support BungeeCord plugins directly, though many popular plugins now ship Velocity-native versions.
Why Velocity Is the Current Default Recommendation
PaperMC's own development focus has shifted to Velocity — Waterfall has moved into a lower-maintenance state as a result, which mirrors the same pattern that made BungeeCord fall behind in the first place. For a new network being set up today, Velocity is generally the recommended starting point specifically because it's where active development and plugin support are concentrated going forward.
When BungeeCord or Waterfall Might Still Make Sense
An existing network already running BungeeCord-specific plugins without Velocity equivalents, or deeply reliant on legacy forwarding configurations, might reasonably delay migration until those dependencies are resolved — rewriting a whole network's proxy layer isn't always a trivial weekend project, even when the destination is clearly better long-term.
Plugin Compatibility Is the Real Migration Blocker
The proxy software itself is rarely the hard part of switching — checking whether every proxy-side plugin currently in use (chat bridges, punishment syncing, queue systems) has a Velocity-compatible version is usually what determines how straightforward a migration actually is.
The Short Version
For a brand-new network: Velocity. For an existing BungeeCord/Waterfall network without a pressing reason to migrate: evaluate plugin compatibility before committing to a timeline, but plan for Velocity as the eventual destination given where active development is heading.