Hacker News Reader

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.

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.

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.

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.

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

Reply on news.ycombinator.com