Comment by flefto

5 years ago

So use a separate database.

Is contention with the application your only objection? That’s pretty weak.

What’s the real compelling reason not to use a database? You haven’t said.

10 comments

flefto

Reply
hughrr  5 years ago

Contention, architectural separation, you have to build your own monitoring stack, not transactional with concerns outside the database without introducing distributed transactions and risk, no routing or distribution capability, you have to build it yourself, point in time message durability is somewhat dubious depending on your acknowledgement process which of course you had to invent yourself as well.

Not to mention numerous database administrators crying into their cups of coffee.

Enough?

Like I said 20 years of people fucking this up is my experience.

  • flefto  5 years ago

    Meh. All your objections are hand wavey and not factual.

    Databases actually work fine as a queue but emotionally you don’t like it. That’s fine it’s just not real strong objections.

    What you have not said is “it physically does not work”, and that’s because it does work fine.

    • phildawes  5 years ago

      I don't think he's saying 'it cannot be physically made to work (given enough effort and discipline)'. The impression I got was more like 'if you go down this route then the incremental path of least resistance leads somewhere bad'.

    • rmetzler  5 years ago

      The range where databases work fine is pretty small. Sudden spikes in job creation will kill the performance of the database. Often enough the job creations come from external systems you can't control.

    • hughrr  5 years ago

      I’m not saying it doesn’t work. I’m saying you’re shooting your toes off down the line.

  • deskamess  5 years ago

    > you have to build your own monitoring stack,

    How is this done in Redis automatically? At some point you are writing queries (albeit Redis ones) to pull metrics. Other queueing systems may expose an API but there is always some level of integration. With Postgres/other db I would write SQL which is their API and a powerful one at that.

    I can couple events with triggers to auto-generate other events etc, have built in audit capability, roll up reporting etc, all with standard SQL. (all in the context of monitoring and reporting)