[gavinhoward]

SQLite has the option to run on a pure in-memory database.

[remram]

SQLite is not a server, you can't use it as a shared cache or job queue or pubsub mechanism.

On the other hand Redis is a bad database so I would say the use cases don't overlap.

[andrewstuart]

You can use SQLite as a queue it is better suited to the task than redis.

SQLite supports atomic operations - the key requirement of a message queue.

[aneutron]

That is a very bold claim. A message queue can have many different requirements: Some message queues tolerate lost messages, others don't. Some require a notification mechanism (i.e. a push model instead of a polling model). Other require precise management of dead letters.

All this to say that, yes, you theoretically CAN use SQLite as a message queue. But atomic operations are usually WAY lower on the "must have" list for a message queue than other parameters.

The easiest way you could verify this is by looking at the guarantees provided by some of the most known MsgQueues.

[andrewstuart]

Atomic operations are the baseline requirement for implementing a queue.

This is what ensures only one reader gets a message. SQLite has it, redis does not.

[remram]

> is better suited to the task than redis

That is a claim not an argument, and again it can't be a shared queue because no networking.

Or do you believe Redis doesn't have atomic operations?