Probably not, the limiting factor for most database systems, even of the plain old boring scale-up not scale-out SQL kind, is disk IO. Before SSDs and virtualized storage, it was all about having cabinets full of disks (usually in expensive SANs) for fast database applications. Enterprise hard disk drives only gave you low triple digit IOPS, I think the highest I've ever read in a 2.5" HDD is about 450 IOPS.
If you wanted data resiliency, you used RAID60 or RAID10 or some exotic variant that would usually give you on the order of a 30-50% reduction in capacity and sometimes as much as a 75% reduction in write IOPS - it's always been the writes that have been killer, that's the stuff you need to make sure persists. RAID6 with a crappy controller or on an overloaded good controller would make you pay the write hole tax.
Commodity SSDs give you up to, if you're willing to take peak numbers, on the order of 45,000 IOPS. To get to that kind of performance in the last decade, you'd need a cabinet with between 200 and 400 2.5" HDDs, depending on everything involved.
Now, that's all 2000s era stuff. The future is bright, thanks to virtualized storage arrays turning commodity storage into massive virtual SANs with tiered storage on consumer SSDs being used like race tires, consumables replaced periodically to maintain top performance, and so on. Even so, the biggest benchmarks I've seen for enterprise systems with multiple 10GbE adapters running raw disk IO has been on the order of 1 million IOPS. I'm sure exotic systems will put out higher numbers, after all there are machines that support over 100 physical CPUs, but they aren't attainable and certainly aren't a broad market.
All of those words were said to essentially say that databases have almost always been constrained by disk IO. The SDN controller in the paper? Limited if any disk IO. A SQL database? It probably could be written in naive, pre-java.nio Java and still IO limitations would dwarf the overhead of the language. (There are exceptions, I'm ignoring certain overheads, etc.)
Maybe a NoSQL solution in Haskell would scream with this new IO manager, but I suspect it's going to be correctness rather than performance that drives anyone to implement their database in Haskell right now.
And high concurrency tends to break MySQL easily. DB is always the bottleneck here, always.