"In the past five years, flash memory has progressed from a promising accelerator, whose place in the data center was still uncertain, to an established enterprise component for storing performance-critical data. It's rise to prominence followed its proliferation in the consumer world and the volume economics that followed. With SSDs, flash arrived in a form optimized for compatibility - just replace a hard drive with an SSD for radically better performance. But the properties of the NAND flash memory used by SSDs differ significantly from those of the magnetic media in the hard drives they often displace. While SSDs have become more pervasive in a variety of uses, the industry has only just started to design storage systems that embrace the nuances of flash memory. As it escapes the confines of compatibility, significant improvements in performance, reliability, and cost are possible."

Of course, but you still either have to battery-back it or sync it to non-volatile storage at some point if you're not working with transient data.

Usually you'd run temporary tables in there (eg web session data) so only non-persistent data would be lost. Much like how RAM is used normally in fact.

However I have seen RAM disks used for persistent data as well. The set up of that will differ from DBA to DBA, but used generally expect them to have a real time sync (either via a duplicate database server mirrored via TCP/IP link) or a RAID mirror locally (using a battery backed hardware RAID controller), then the whole lot sat on top of a UPS. (much of that is standard gear even without running persistent data on RAM disk though)

My point was that, of all the common types of on-disk formats, a database is probably the most suited to an architecture where there's no distinction between RAM and permanent storage.

That depends entirely on the database engine. But in general you'd be right.