Any reasons not to use a Redis server for data exchange?

There's a lot of posts about MQTT, but the client has a relatively large memory footprint whcih can be a problem on small micros such as the mega328.

Redis does a similar thing to MQTT but is simpler (has less features) and therefore the library is smaller (much smaller if you only need to send/receive char arrays) , however I don't see many people using it for microcontrollers. It's mainly used as an in-memory cache for enterprise scale apps.

Installing the server on Windows/Linux is easy and there's not much to configure other than the listening port.
I know MQTT supports SSL and Redis doesn't have any security features as such, but with a small micro you're not going to have enough memory or CPU to do that anyway.

So how did MQTT end up as the defacto standard and few are using Redis?
Is it that most users are using the wireless ESP8266 and therefore memory is a non issue?

There’s a lot of posts about MQTT, but the client has a relatively large memory footprint whcih can be a problem on small micros such as the mega328.

Which client library are you using? The PubSubClient runs perfectly on an ATmega328p based board.

Redis is a key-value store or in other words a simple but fast database.
MQTT is a message distribution system where a subscriber is informed if the value changes.

Both system has completely different feature sets although you can construct a greatest common denominator but that is minimal.

MQTT is a great choice if you want to share sensor data with other interested parties. Redis is a good choice if you have to store and access it again very fast.
I don’t see any usage for Redis in my embedded projects but I used MQTT quite extensively.

Is it that most users are using the wireless ESP8266 and therefore memory is a non issue?

Again, memory is no problem if you use MQTT, I have several ATmega328p sending data to a Mosquitto server.

pylon:
Redis is a key-value store or in other words a simple but fast database.
MQTT is a message distribution system where a subscriber is informed if the value changes.

Both system has completely different feature sets although you can construct a greatest common denominator but that is minimal.

Not quite true. Aside from the key-value store Redis also has a publish/subscribe capability just like MQTT except without the QOS levels.

The 'retained messages' feature of MQTT is basically a one level deep key-value database whereas the Redis database can be many layers deep.

Not quite true. Aside from the key-value store Redis also has a publish/subscribe capability just like MQTT except without the QOS levels.

Didn't know that. Do you know anyone using that?

The 'retained messages' feature of MQTT is basically a one level deep key-value database whereas the Redis database can be many layers deep.

What is a level or layer in this context? Does Redis support versioning of the stored data?

pylon:
Didn't know that. Do you know anyone using that?

What is a level or layer in this context? Does Redis support versioning of the stored data?

I think the Redis pub/subscibe feature is overshadowed by it's typical use in the enterprise which is as a high speed set/get cache. Unlike MQTT there's no QOS1 or 2 to guarentee delivery of subscribed messages which may be a problem in mission critical systems.

From what I can tell it's main selling point is the high transaction throughput. I see 35k per sec between two 10 year old desktop PCs connected to the same ethernet switch.

In terms of versioning Redis gives you the option of appending data to a key effectively creating a stack of data objects with the most recent at the end.