Design the data store for a time-series metrics table taking millions of writes a minute, almost always queried as "last hour for this one metric key," rarely updated once written. Why does the storage engine underneath the database label matter more than whether it's called "SQL" or "NoSQL"?

This workload — extremely high write volume, append-heavy, almost never updated, and reads that go through one known access pattern (metric key plus a recent time range) — is close to the textbook fit for a write-optimised storage engine, which is what actually decides the read/write trade-off, not the "relational" or "wide-column" label on the box. A B-tree engine (Postgres, MySQL) modifies pages in place, which costs random disk I/O on every write and is why a single Postgres primary tops out around tens of thousands of writes a second. An LSM-tree engine (Cassandra, RocksDB) never modifies in place — writes go to an in-memory buffer and a sequential append-only log, both cheap — pushing the cost to reads, which may have to check several files on disk. For this workload, the LSM-tree side wins on writes and loses nothing on reads, because the one query pattern (metric key, recent range) is exactly what the engine is built to serve fast.