Google's (Postgres-compatible) AlloyDB Omni also has similar functionality now - the main DB action, persistence, etc still has to land on persistent block storage, but additional data can be cached for reading on local NVMe disks.

Oracle's Exadata is a whole another beast (I co-authored a book about it back in 2010 and it has improved even further since then). It's a hybrid, shared storage distributed system - not consensus-based replication (although they support RAFT for global data systems now too), but a distributed, coherent buffer cache (global cache) based database system. As it's shared storage, you can write copies of blocks, WAL to multiple separate storage cells (NVMe or even just remote RAM) via direct RDMA operations, without OS kernel or system calls involved.

For analytic queries, yep Oracle can push down filtering, column projection, many aggregations and join filters (bloom filters) for early filtering into the storage cells. The bloom filters are used for early filtering of the next table in the join, based on the output of the previous query plan nodes so far.

Based on the docs Neon has in GitHub, I have to disagree. The mechanisms are similar, esp how the Page Server keeps some pages cached locally, but they serve different goals. The Page Server cache and WAL consensus are both temporary storage.

In tiered storage databases individual tables or rows would move automatically and permanently between different mediums according to some criteria. eg: Latency sensitive data on nvme near the user, frequently accessed data stored on nvme and replicated globally, infrequently accessed data stored on spinning disks, etc.