This article isn't complete. Some areas which can be misleading:
1. "In terms of read/write performance the SDD is capable of achieving in excess of 240 MB/sec whereas the disk drive maxes out at around 100 MB/sec."
Raw read and write times are valuable for mechanical hard disks, but are relatively worthless when evaluating the difference an SSD makes. With an SSD the most important measurements are your 4k and 4k-64 times (1024) small file read/write times directly tied to the size of files dependents on your file system. It's nice to know currently SSD's can read/write in excess of 500mbps, but it's far more important to know their 4k times are exceeding 20mbps reads and nearly 100mbps writes and their 1024 files are over 200mbps read and write. Because when you compare these numbers you can see the huge performance differences which really count.
As an example, download AS SSD benchmarking software
. I like this one because I think it more closely emulates a image based work flow. What this does is it reads and writes a set number of files and records the time. This number of files remains the same for any device it tests. The Intel 520 256gb SSD I reviewed here
completes this entire test in 10-15 seconds. Fast enough so you'll sit there waiting for the result. A 10,000 RPM modern Raptor takes over an hour. An average laptop drive can take several hours. Remember, they're all reading and writing the same number of same size files, but an SSD is doing it in 10-15 seconds, and a mechanical hard drive an hour to hours.
But there's more. You can't assume this huge performance difference will translate directly to ANY application. These performance numbers relate to specific tasks.. so you need to understand what tasks your application will benefit the most from, and if an SSD will therefore benefit your application. This takes a lot more knowledge and testing than we're used to with mechanical HDD's. However, the OP asked about catalog/previews.. if you're going through your archives sorting or looking for specific images.. this type of tasking is ideally suited for the performance benefits of an SSD.. this is why everyone is saying they see a huge difference in performance when going through their libraries. And why I said above the size and structure of your library/previews will see the more performance benefits the larger their sizes are.
Let's say your library/previews are on a fast SSD. With CPU/RAM performance constant, you will be able to search for an display those previews significantly faster than if they were on an HDD. However, once you choose an image to be processed and exported and if that file is on a HDD.. then the performance increases of the SSD will seem much less because the CPU/RAM becomes the bottleneck.
2. On the tests in this article where he's importing. I'm not seeing what he's importing from. Are the images being brought in from a flash card and flash card readers (both serious potential bottlenecks), or are they being imported from an existing location on a hard disk. I'm not seeing where this is specified.
3. Only one of this tests has all operations on SSD's. All the other tests has at least one file component on an HDD. The first test is "time to import and render 1:1 previews", but it doesn't say where it's importing from and a flash drive/reader are your most significant bottlenecks in this work flow. The second test "time to render 1:1 previews" always has a HDD in the work flow as do the other tests.. where the tasks do need the SSD. In other words, if you assume the HDD is the slowest device (which it is) and it's always in the work flow, then it's always a bottleneck which distorts any performance advantages you might get from the SSD.
4. Bottlenecks are also found in controllers, use of RAM, CPU function, bus speeds, and more. Which means, using the same computer and setup for this type of testing potentially (and probably) is introducing the same bottlenecks in all work flows.. so more distortion.
5. SSD tests by themselves will always state the base computer CPU/RAM and often more. This is when the benchmark is being ran on just the SSD. But when you're trying for benchmarks across the entire work flow and system, then you also need to look really hard at the entire system and this wasn't done. In other words, there could be one or more bottlenecks (and there probably are) throttling the performance advantages of an SSD.
6. With all that said, even in an ideal system with the bottleneck being the SSD itself.. performance gains for certain areas of a lightroom work flow will be negligable, and for other parts of the work flow huge. You need to understand your work flow and where you spend the more time to know if an SSD could potentially improve YOUR work flow. And when I say "potentially" I mean if YOUR system has no other bottlenecks getting in the way of that performance. This is why the guy who designs and builds your system must understand not only computers and other hardware, but the imaging work flow you're using as well. He/She must also understand how the setup parameters affect different performance factors and how these affect work flow, and how drivers can do the same. There really is a lot to an accurate answer to these questions.
7. As you can see there are many variables unique to each individual system and work flow which affects the answer to "will an SSD improve the speed of my work flow. Much." The question simply can't be answered with only an HDD and SSD as the only variables.
8. All I can say with certainty is this. SSD's over dramatic performance increases over HDD's IF the supporting system is void of bottlenecks. These differences are highly dependent on YOUR work flow. Some functions in LR will benefit greatly from an SSD, others marginally.