[aneutron]

It's akin to asking the following:

What does a car do that you can't trivially do with something else ? Like a boat or an airplane ?

You simply cannot compare an in-memory Key-Value store, to a RDBS. And that's on a conceptual level. If you then consider performance, network latency and the guarantees, we're absolutely comparing airplanes to donkeys: You wouldn't use an airplane to climb up a rough mountain, and you certainly wouldn't prefer a donkey to travel to the other side of the world.

[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?