ProxySQL builds three release tiers from one codebase, and the repositories serve one of them

A protocol-aware proxy in front of MySQL, its forks, and PostgreSQL

ProxySQL describes itself as a high-performance, high-availability, protocol-aware proxy for MySQL and its forks, naming Percona Server and MariaDB explicitly, plus PostgreSQL. The license is GPL, and the project frames that as a feature rather than a constraint, saying you get the unlimited freedom that comes with a GPL license. Its stated motivation is narrower still: the development is driven by the lack of open source proxies that provide high performance. That tells you what kind of user it is aimed at. The project also sells subscriptions and support separately, listed alongside the official site, the documentation, a Docker Hub repository, a forum and a blog carrying benchmarks, so the free artifact and the paid relationship are separate arrangements. The last push was on 2026-11-02.

Download a package, or take a distribution agnostic tarball

Released packages live on the repository's releases page, and the simplest install is a download plus your package manager:

wget https://github.com/sysown/proxysql/releases/download/v3.0.4/proxysql_3.0.4-ubuntu24_amd64.deb
dpkg -i proxysql_3.0.4-ubuntu24_amd64.deb

Note how specific that example is. It pins v3.0.4 and an ubuntu24 amd64 package, so the asset name encodes version, distribution and architecture together, and picking the wrong one is a 404 rather than a bad install. Where a deb or rpm is inconvenient there is a distribution-agnostic tar.gz for any glibc 2.34 or newer Linux on amd64 or arm64. It ships with a checksum file next to it, and the documented sequence is to verify before extracting:

sha256sum -c proxysql-<version>-linux-amd64.tar.gz.sha256
tar xzf proxysql-<version>-linux-amd64.tar.gz

The archive contains bin/proxysql, a sample etc/proxysql.cnf, the systemd/ units and helper tools.

OpenSSL 3.5.7 is vendored, and that is not a FIPS claim

The tarball embeds pinned OpenSSL 3.5.7 libraries and does not need host OpenSSL shared libraries, while GnuTLS remains a dynamic runtime dependency. That is a packaging decision with a clear purpose: a host whose OpenSSL is missing, older or built without FIPS will not stop the proxy from starting. The project is careful about what this does not mean, stating that the vendoring is not a FIPS compliance claim and that future FIPS module support is tracked separately in issue #6116. Building from source needs nothing beyond a normal git clone, because the pinned OpenSSL source archive is vendored directly in git, and the tree ships a verification script to run before building dependencies:

deps/libssl/verify-source.bash

Source verification, recovery and the supported patch-update procedure live in doc/vendored_openssl.md, and the patch update path is tracked in issue #6115. If your compliance story needs a validated module, this arrangement does not provide one.

One tree, three tiers, selected by environment variables at build time

The Makefile is where the project's shape is clearest. ProxySQL supports three distinct release tiers built from the same codebase, and the tier is controlled by environment variables that enable feature guards and adjust the version number so the upgrade path stays clear. v3.0.x is the stable tier and the default build, carrying bug fixes and core enhancements with no extra flags. v3.1.x, the innovative tier, is enabled by setting PROXYSQL31=1 and adds FFTO, the Fast Forward Traffic Observer, plus a TSDB time series database subsystem, and the build increments the minor version so 3.0.6 becomes 3.1.6. v4.0.x, the plugin chassis tier, is enabled by PROXYSQL40=1 and adds a four-phase plugin lifecycle splitting register_schemas from init, plus a pre-execution query-hook plugin ABI. For an operator the practical point is that a binary is not just a version number, it is a version number plus a compile-time flag set.

Three releases published on one day means three upgrade paths

The Makefile describes all three tiers as built from the same codebase. Meanwhile the repository's default branch is v3.0, so a plain clone gives you the stable line and not the newest one. Two consequences follow. First, a security fix or a bug fix published for the stable tier may not exist in the tier you compiled, and the reverse also holds, so reading a release note means checking which tier it belongs to. Second, the version number itself is not a reliable indicator of capability: the build increments the minor version when the tier flag is set, so a 3.1 build is not simply a newer 3.0. If you run several deployments, recording which tier each binary came from is the minimum metadata you need.

The MySQL Router plugin ships in source builds only

The v4.0 build includes runtime plugins for MySQL X, GenAI and what the documentation calls the MySQL Router compatibility foundation. The caveat is precise and worth reading twice: the Router plugin is distinct from the MySQL X protocol plugin, and it is not yet included in release packages. Source builds install proxysql_mysql_router.so under /usr/lib/proxysql/plugins/, so testing Router compatibility against ProxySQL means compiling. If your reason for looking at ProxySQL is a migration away from MySQL Router, that is the cost line. A related document covers optional AWS locality-aware backend selection under doc/aws-locality-awareness.md, which describes an external-provider contract and MySQL configuration controls, so region-aware routing is also a build-and-configure project rather than a switch.

Every documented repository path sits under proxysql-3.0.x

Official repositories are provided for the major distributions, and every URL in them carries the same proxysql-3.0.x segment: the Debian and Ubuntu path ends in the distribution codename from lsb_release -sc, the Red Hat path uses $releasever, Amazon Linux points at centos/8, Almalinux uses its own $releasever, and OpenSUSE uses $releasever_major with a gpgcheck line. On Ubuntu and Debian the keyring is fetched into /etc/apt/trusted.gpg.d before the source line is written, and then the package installs with apt-get install proxysql, or a pinned apt-get install proxysql=version. FreeBSD is the exception that needs no repository at all:

pkg install proxysql

or from ports with cd /usr/ports/databases/proxysql/ && make install clean. Since the repository path names the stable tier, an operator who needs the v3.1 or v4.0 feature set is installing from release assets, not from the distro channel.

Editorial conclusion

ProxySQL fits an operator who needs a high-performance, high-availability, protocol-aware proxy in front of MySQL and PostgreSQL and who is prepared to compile for a specific tier rather than take whatever a package manager offers. It is the wrong tool if your requirement is MySQL Router compatibility from a release package, because that plugin ships only in source builds, and it is the wrong tool if your compliance paperwork needs a FIPS validated module, since the vendored OpenSSL is explicitly not a FIPS claim. Before you install, check three things: which tier you actually want, because the default build is the stable one and the other two need PROXYSQL31=1 or PROXYSQL40=1; whether your distribution's repository path matches your tier, since the documented repository URLs all sit under proxysql-3.0.x; and which licence obligations GPL places on you, separately from the paid subscriptions and support the project sells.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. sysown/proxysql on GitHub