Key-value for the relational mind

If your career has been built on PostgreSQL, MySQL, or Oracle RDBMS, key-value databases can look like a strange animal: no schema, no joins, no SQL, and durability that’s optional by design. So where does it actually belong in your architecture? Why do so many applications tend to use both a relational database and a key/value database? This session answers that from a relational-first perspective. We place Valkey precisely in the stack: not as a replacement for your RDBMS, but as the tier that absorbs the work your database shouldn’t be doing : hot reads, session state, rate limiting, queues, leaderboards, and massive write scale workloads. We’ll translate concepts you already know: how cache-aside, read-through, and write-behind map to real query patterns; why a sorted set beats an indexed table for a leaderboard; and how concurrency, replication, and persistence options (RDB/AOF) line up against the MVCC, WAL, and ACID guarantees you rely on every day. Just as importantly, we’ll cover when not to reach for it, and how to spot the queries in your existing workload that are quietly begging to be offloaded. You’ll leave being able to look at a strained Postgres or MySQL instance and identify concretely what belongs in Valkey, what stays relational, and exactly where the boundary sits.