2 ms·

What does Redis do that you can’t do trivially with something else? Postgres or SQLite for example.

aneutron 2y ago
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 2y ago
  SQLite has the option to run on a pure in-memory database.
  - remram 2y ago
    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 2y ago
      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 2y ago
        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 2y ago
        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 2y ago
        > 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?

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 2y ago
SQLite has the option to run on a pure in-memory database.
- remram 2y ago
  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 2y ago
    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 2y ago
      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 2y ago
        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 2y ago
      > 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?