As it's part of the memory domain, not some external block device, the CPU caches can cache it (64B cache line sizes) and maintain cache coherency across CPUs, NUMA nodes (and soon with CXL 3.x ?) across memory pools shared by many servers. So your programming model will be just using CPU loads & stores to access the individual bytes you need directly from the Optane storage, instead of having to do some 512B or 4kB DMA or memcpy to RAM first and then access what you needed. And it's persistent, so you won't need to have a separate layer of code for persisting your "cache" of data... One can ditch the "database block I/O" and "buffer cache" notion and just treat Optane as byte-addressable RAM on a server that will never reboot or crash... Of course in reality your server can always catch fire or have a hardware malfunction, so you'd need to replicate your data to some distant enough backup or DR instance... which (at least in mission-critical database context) negates some of the value of persistent low-latency I/O... If you need to wait for 1+ms for the remote WAL write to be acknowledged from a different AZ or region anyway, then having an 1 us local Optane write is not gonna change the whole commit latency that radically.