Describe the bug
In 5.2.3 exporting streams data straight to the client while 6.x writes to the file system. Once the export is complete in 6.x, the entire file is then sent at once to an output buffer spiking the memory.
I believe this to be a regression. Because of unpredictable ram spikes, the app cannot be deployed to a restricted kubernetes environment.
I have not looked at the code but the regression is present in the latest snapshots as of July 2026.
How to Reproduce
- Export plain or gzipped, behaves the same
- If in a containerized env with memory limits and if the export is large enough a ram spike at the end of the export will cause the orchestration system to kill the app.
- My 330MB plain text dump spikes the ram to 1100 MB, 70MB gzipped dump spikes it to 300 MB. Idle container is ~25MB
Expected behavior
Streamed output
Screenshots
No response
Operating System
Linux
Web Server
nginx fastcgi pass to php-fpm
Database Server
MariaDB
Database version
No response
PHP version
tested with 8.4-latest
phpMyAdmin version
6
browser
No response
Additional context
No response
Describe the bug
In 5.2.3 exporting streams data straight to the client while 6.x writes to the file system. Once the export is complete in 6.x, the entire file is then sent at once to an output buffer spiking the memory.
I believe this to be a regression. Because of unpredictable ram spikes, the app cannot be deployed to a restricted kubernetes environment.
I have not looked at the code but the regression is present in the latest snapshots as of July 2026.
How to Reproduce
Expected behavior
Streamed output
Screenshots
No response
Operating System
Linux
Web Server
nginx fastcgi pass to php-fpm
Database Server
MariaDB
Database version
No response
PHP version
tested with 8.4-latest
phpMyAdmin version
6
browser
No response
Additional context
No response