ProxySQL 3.1.6: Full Query Observability in Fast Forward Mode with FFTO
ProxySQL’s Fast Forward mode has always been the go-to for maximum throughput scenarios — replication streams, bulk data loads, high-frequency trading feeds — where you need ProxySQL as a transparent pipe with minimal latency overhead. The trade-off? You gave up query-level visibility. Fast Forward connections were a blind spot in your monitoring.
ProxySQL 3.1.6 changes that with the Fast Forward Traffic Observer (FFTO).
The Problem: Fast Forward’s Visibility Gap
In standard mode, ProxySQL intercepts every query. It parses the SQL, generates digests, tracks execution time, counts rows, and feeds all of this into stats_mysql_query_digest and stats_pgsql_query_digest. This is the foundation for capacity planning, slow query detection, and workload analysis.
But when you configure a user with fast_forward=1, ProxySQL switches to transparent proxying — forwarding packets directly between client and server without deep inspection. This is intentional: some workloads need raw throughput and cannot tolerate the overhead of full query processing.
Small note: in Fast Forward mode ProxySQL does a lot more than a layer 4 proxy: it is still able to combine mix and match compression and TLS
The problem is that Fast Forward connections were effectively invisible. They showed up as aggregate bytes transferred, but you had no idea what queries were running, how long they took, or how many rows they returned. For DBAs running replication through ProxySQL, or routing specific high-throughput application paths through Fast Forward, this was a real operational gap.
How FFTO Works
FFTO is a passive observer that sits alongside the Fast Forward data path. It inspects the protocol stream — without modifying it — and extracts query metadata in real time.
The key design principles:
- Zero modification: FFTO never touches the forwarded data. It reads protocol packets that have already been decrypted and decompressed by ProxySQL’s session handler.
- Protocol-aware state machines: Separate implementations for MySQL and PostgreSQL wire protocols, each tracking the full lifecycle of queries from request to response.
- Graceful degradation: If a single packet exceeds a configurable buffer limit (default 1 MB), FFTO disables itself for that session only. Other connections are unaffected. No crashes, no stalls, no memory runaway.
- Metric parity: FFTO feeds into the same
stats_*_query_digesttables as standard mode, so your existing monitoring queries and dashboards work unchanged.
What Gets Captured
For every query flowing through a Fast Forward connection, FFTO records:
| Metric | Description |
|---|---|
| SQL digest | Normalized query text and hash, identical to standard mode |
| Execution latency | Microsecond-precision timing from request to first response |
| Rows sent | Number of rows returned by SELECT queries |
| Rows affected | Number of rows modified by INSERT/UPDATE/DELETE |
| Error tracking | Error codes for failed queries |
| Count | Execution count per digest |
Full Protocol Support
FFTO handles the complete protocol surface for both MySQL and PostgreSQL:
MySQL:
- Text protocol (
COM_QUERY) — standard SQL statements - Binary protocol (
COM_STMT_PREPARE,COM_STMT_EXECUTE) — prepared statements with parameter binding - Statement ID tracking — maps
stmt_idvalues back to the original SQL template
PostgreSQL:
- Simple query protocol (
Querymessages) - Extended query protocol (
Parse→Bind→Execute) — including named statements and portals - Pipelined queries — correctly attributes responses to the right query in a pipeline
Getting Started
FFTO is enabled by default in ProxySQL 3.1.6. If you already use Fast Forward mode, query digests will start appearing in your stats tables with no configuration changes.
To verify it’s working:
-- Check that FFTO is enabled
SELECT * FROM global_variables WHERE variable_name LIKE '%ffto%';
-- Run queries through a Fast Forward connection, then check:
SELECT hostgroup, count_star, sum_time, digest_text
FROM stats_mysql_query_digest
ORDER BY sum_time DESC;Configuration
Two variables per protocol control FFTO behavior:
-- Enable/disable (enabled by default)
SET mysql-ffto_enabled='true';
SET pgsql-ffto_enabled='true';
-- Max buffer size per packet (default 1MB, range 1 byte to 1GB)
SET mysql-ffto_max_buffer_size=1048576;
SET pgsql-ffto_max_buffer_size=1048576;
LOAD MYSQL VARIABLES TO RUNTIME;
LOAD PGSQL VARIABLES TO RUNTIME;The buffer size limit controls memory usage per session. If a single protocol packet exceeds this limit (e.g., a 50 MB BLOB insert), FFTO bypasses observation for that session to avoid excessive memory consumption. The Fast Forward data path continues working normally — only the monitoring is disabled for that connection.
Performance Impact
FFTO was designed with a strict performance budget of less than 5% throughput impact. The implementation achieves this through:
- Passive inspection — no packet copies or modifications on the forwarding path
- Thread-local digest caching — avoids lock contention on the Query Processor cache
- SpookyHash — fast, consistent hashing for query normalization
- Per-session isolation — bypass decisions are local and don’t affect other connections
For most workloads, the overhead is negligible. The only scenario where you might see measurable impact is very high packet rates with complex prepared statement protocols, where the state machine tracking adds a small per-packet cost.
Use Cases
High-throughput application paths: Applications that use Fast Forward for performance-critical queries can now get full query analytics without sacrificing throughput.
Mixed-mode deployments: Run some hostgroups in standard mode (full processing, caching, routing) and others in Fast Forward (raw throughput), while maintaining unified query visibility across both.
Compliance and auditing: Environments that require complete query logging can now use Fast Forward mode without losing audit trail coverage.
Conclusion
FFTO eliminates the oldest trade-off in ProxySQL’s architecture: choosing between performance and observability. With ProxySQL 3.1.6, Fast Forward mode is no longer a monitoring blind spot. Every query — text or binary, MySQL or PostgreSQL, simple or pipelined — gets captured in your digest tables with the same fidelity as standard mode.
ProxySQL 3.1.6 is available now. Upgrade and check your stats_*_query_digest tables — you might be surprised by what your Fast Forward connections have been doing.