Why do sequential writes have better performance than random writes on SSDs?

Solution 1:

A reasonably concise explanation by Seagate on how garbage collection is responsible for the difference in SSD performance for random versus sequential writes:

... the need for garbage collection affects an SSD’s performance, because any write operation to a “full” disk (one whose initial free space or capacity has been filled at least once) needs to await the availability of new free space created through the garbage collection process. Because garbage collection occurs at the block level, there is also a significant performance difference, depending on whether sequential or random data is involved. Sequential files fill entire blocks, which dramatically simplifies garbage collection. The situation is very different for random data.

As random data is written, often by multiple applications, the pages are written sequentially throughout the blocks of the flash memory.
The problem is: This new data is replacing old data distributed randomly in other blocks. This causes a potentially large number of small “holes” of invalid pages to become scattered among the pages still containing valid data. During garbage collection of these blocks, all valid data must be moved (i.e. read and re-written) to a different block.
By contrast, when sequential files are replaced, entire blocks are often invalid, so no data needs to be moved. Sometimes a portion of a sequential file might share a block with another file, but on average only about half of such blocks will need to be moved, making it much faster than garbage collection for randomly-written blocks. ...

Solution 2:

Another explanation is that sequential I/Os are easier to coalesce at all levels. Generally you have less overhead when you send the same data but using fewer but bigger I/Os thus you can reach a higher throughput by coalescing. You would have to prove whatever kernel you were using didn't batch your sequential I/Os up into bigger I/Os thus reducing overhead and improving the performance in comparison to what it had to do for random I/O.