The relative scarcity of NVMe ports/bandwidth per server may make that as unattractive as doing the (RAM) caching on the database server itself, but it's not obvious, if one could only spend the money in one place, where it would be best spent.
The relative scarcity of NVMe ports/bandwidth per server may make that as unattractive as doing the (RAM) caching on the database server itself, but it's not obvious, if one could only spend the money in one place, where it would be best spent.
Historically, I've had trouble convincing management to get anywhere close to reaching the capacity of a server's PCIe lanes, possibly because of a general ignorance around direct attached (but external) storage options, but the popularity of NVMe may change that.
Now the challenge may become convincing people that 128 lanes per CPU is better than 40.
There's also the (extension of the perpetual challenge) that the mere existence of such a price-competitive option to Intel means one doesn't have to panic at the slightest hint of scale and invest immense engineering effort and non-linear infastructure cost into a distributed database to replace a "single"/central [1] RDMBS.
[1] With all the usual replicas and caches for performance (and failover), as is the point of the article.