AWS Glue ETL Performance: JDBC Pushdown and DPU Scaling

Quick Answer

Reducing both runtime and cost on a slow Glue job usually means attacking two separate things: how much data has to move across the network, and how much parallel compute is available to process it. Pushdown predicates let the JDBC connection filter rows at the source MySQL database itself, before the data is ever pulled into Glue, so instead of transferring the full 50-million-row table and filtering afterward, only the relevant subset crosses the network, which directly cuts the data volume the job has to handle on every run. Increasing the number of DPUs (data processing units) adds more parallel compute capacity to the Glue job, which lets it process the filtered data faster once it's in hand. These two changes are complementary rather than redundant: pushdown predicates shrink the problem before it reaches Glue, and more DPUs speed up the processing of whatever remains, so applying both compounds the runtime improvement rather than each working in isolation. This combination is especially relevant for a continuously updated source table, since filtering at the source avoids reprocessing rows that haven't changed, which a purely compute-focused fix like adding DPUs alone wouldn't achieve. Whenever a Glue performance question involves a JDBC source and both cost and runtime need to improve, look for an answer that combines filtering data as early as possible with adding compute parallelism, rather than relying on just one of the two.