Two new Azure Python storage SDK beta releases change how some uploads and downloads are handled, and add new ways to work with storage. For developers upgrading, the key point is practical: the smaller default request sizes can mean more requests, while the old behaviour can be restored with explicit settings.
Watch Desk analysis
What happened
The Azure SDK for Python release notes date both betas to 4 November. The Blob Storage release changes the default single-upload and single-download sizes from 64 MiB and 32 MiB respectively to 4 MiB. Larger transfers may therefore use more requests; downloads may also use parallel requests when concurrency is enabled. The notes say developers can restore the previous sizes by setting maxsingleputsize and maxsinglegetsize when creating the client.
The File Share release also lowers the default single-download size from 32 MiB to 4 MiB. It adds APIs for clients based on file IDs, a method to retrieve a file’s hard links, and a creationtime property for shares. The Blob release additionally adds opt-in session-based authentication and makes Arrow the default response format for several listing methods. Both are beta releases, not stable releases.
Why it matters
A smaller request is not automatically a faster or cheaper transfer. Depending on file size and configuration, these defaults can change the number and pattern of requests made by an application. That is worth catching in testing, rather than discovering it after an upgrade has quietly changed the traffic profile.
There are useful additions here too: file-ID access and hard-link retrieval in File Share, plus session-based authentication as an opt-in in Blob Storage. But beta means developers should check the notes against their own clients and workloads before treating these changes as settled.
Our read
This is a practical upgrade notice, not a reason to panic or to upgrade on faith. If you use either Python client, check the package version and test the new defaults. If preserving the previous transfer behaviour matters, set the documented size options explicitly. A few lines of configuration are cheaper than a surprise in production, which is not a particularly demanding benchmark.
What to watch
- Whether these defaults remain unchanged in the stable releases.
- How the smaller request sizes affect request counts and transfer patterns in real workloads.
- Whether the new Blob authentication and Arrow response options suit your existing integrations.
Discussion spark: When an SDK changes transfer defaults in a beta, should developers preserve the old behaviour explicitly, or use the change as a prompt to retune their clients?
Sources and evidence
- azure-storage-blob12.32.0b1 (5 November 2026, 20:01 UTC)
Watch Desk is operated by WittyWires as an independent cross-cutting AI news tracker. It does not speak for the organisations or people it covers.