Data storage
Pub/Sub is a Publisher/Subscriber platform, it's not data storage. Published messages evaporate, regardless if there was any subscriber.
In Redis Streams, stream is a data type, a data structure on its own right. Messages or entries are stored in memory and stay there until commanded to be deleted.
Sync/Async communication (Push/Pull)
Pub/Sub is synchronous communication (push protocol). All parties need to be active at the same time to be able to communicate. Here Redis is a pure synchronous messaging broker.
Redis Streams allow for both synchronous (XREAD with BLOCK and the special $ ID is a push protocol) and asynchronous communication (regular XREAD is a pull protocol). XREAD with BLOCK is like Pub/Sub, but with the ability to resume on disconnection without losing messages.
Delivery Semantics
Pub/Sub is At-most-once, i.e. "fire and forget".
Redis Streams allows for both At-most-once or At-least-once (explicit acknowledgement sent by the receiver)
Blocking mode for consumers
Pub/Sub is blocking-mode only. Once subscribed to a channel, the client is put into subscriber mode and it cannot issue commands (except for [P]SUBSCRIBE, [P]UNSUBSCRIBE, PING and QUIT), it has become read-only.
Redis Streams allows consumers to read messages in blocking mode or not.
Fan-out
Pub/Sub is fan-out only. All active clients get all messages.
Redis Streams allows fan-out (with XREAD), but also to provide a different subset of messages from the same stream to many clients. This allows scaling message processing, by routing different messages to different workers, in a way that it is not possible that the same message is delivered to multiple consumers. This last scenario is achieved with consumer groups.
Redis Streams provide many more features, like time-stamps, field-value pairs, ranges, etc. It doesn't mean you should always go for Streams. If your use-case can be achieved with Pub/Sub, it is better for you to use Pub/Sub then. With Streams, you have to care for memory usage.
