It's not that simple. The FTL addresses two fundamental problems with flash - slow random write performance and wear leveling. It works beautifully on consumer hardware, but performs rather poorly in an enterprise environment. For some workloads you can squeeze a lot more than 5-10% improvement out of the drives. But that's not the interesting part (most of today's workloads are read-intensive anyway).

The interesting part comes from being able to execute existing operations in fundamentally different ways. When you're not restricted to sequential reads you can implement a huge chunk of database internals differently - different concurrency models, different implementations of certain joins, etc. This is where the bulk of the performance improvement comes from.

Once you do this, you realize that a traditional bottleneck (I/O) is completely blown away. Suddenly, all kinds of things nobody ever bothered to optimize become performance bottlenecks (for example, the query plan is traditionally interpreted, not compiled to native code - not good enough once you get an I/O subsystem that's 250 times faster than what you used to have).

Once you get rid of the software bottlenecks, you realize that you're limited by the bus. Since SSDs are highly parallelized devices, you have to change the way you interleave operations for optimal performance. That alone is another order of magnitude.

In three years or so, the flash manufacturers will put chips on the SSDs that will allow you to send down programs to them (not unlike the shaders in video cards). That will likely be a bigger revolution than SSDs themselves. Where we are now is just the beginning.

You're right that we haven't shown any evidence that our approach is anything but a niche. We will. This stuff just takes a long time to build.