<story><title>What is ‘skip locked’ for in PostgreSQL 9.5? (2016)</title><url>https://blog.2ndquadrant.com/what-is-select-skip-locked-for-in-postgresql-9-5/</url></story><parent_chain><item><author>dom0</author><text>&amp;gt; Why use a database as a queue?&lt;p&gt;Already have a central, configured and monitored server and need &amp;quot;just a small queue&amp;quot; for something. This is not per se a bad decision. For the same reason it doesn&amp;#x27;t have to be a bad idea to cache things in the main database, instead of using a dedicated cache like Redis.</text></item><item><author>brianwawok</author><text>Why use a database as a queue? It is known this doesn&amp;#x27;t scale well nor work particularly well. If you need big scale, you can get something like RabbitMQ or Kafka. If you want to avoid server setup, use SQS or Cloud Pub&amp;#x2F;Sub. If you want it to be lighter weight, use Redis.&lt;p&gt;This is kind of like an article talking about how most people use a hammer to put in screws wrong. Which is cool, and good for learning why using a hammer to put in screws is a bad idea. But the outcome of this all should be &amp;quot;Use a proper tool for the job&amp;quot;, not &amp;quot;try to come up with a neat trick to make this work in the wrong system&amp;quot;.</text></item></parent_chain><comment><author>BurningFrog</author><text>In my experience, the cost of adding and maintaining another storage subsystem to a project is often hugely underestimated. It&amp;#x27;s easy to see the benefits and ignore the costs.&lt;p&gt;If I can solve a problem reasonably well by adding a table to my Postgres DB, that will always beat out adding the specialized ScrewdriverDB that does it perfectly.</text></comment>
<story><title>What is ‘skip locked’ for in PostgreSQL 9.5? (2016)</title><url>https://blog.2ndquadrant.com/what-is-select-skip-locked-for-in-postgresql-9-5/</url></story><parent_chain><item><author>dom0</author><text>&amp;gt; Why use a database as a queue?&lt;p&gt;Already have a central, configured and monitored server and need &amp;quot;just a small queue&amp;quot; for something. This is not per se a bad decision. For the same reason it doesn&amp;#x27;t have to be a bad idea to cache things in the main database, instead of using a dedicated cache like Redis.</text></item><item><author>brianwawok</author><text>Why use a database as a queue? It is known this doesn&amp;#x27;t scale well nor work particularly well. If you need big scale, you can get something like RabbitMQ or Kafka. If you want to avoid server setup, use SQS or Cloud Pub&amp;#x2F;Sub. If you want it to be lighter weight, use Redis.&lt;p&gt;This is kind of like an article talking about how most people use a hammer to put in screws wrong. Which is cool, and good for learning why using a hammer to put in screws is a bad idea. But the outcome of this all should be &amp;quot;Use a proper tool for the job&amp;quot;, not &amp;quot;try to come up with a neat trick to make this work in the wrong system&amp;quot;.</text></item></parent_chain><comment><author>IgorPartola</author><text>This. Also, things like RabbitMQ are complex and their durability properties can be different than those provided by your RDBMS. This can get problematic if you are mixing tasks in the queue that have different priorities. For example, emailing the invoice to a client should not fail silently and should happen at most once. Same with a notification from your doctor that you need to call to discuss your test results. Tossing that into an ephemeral queue is probably not the best solution.&lt;p&gt;Having said that, RabbitMQ does have a ton of settings where you can turn durability up&amp;#x2F;down as much as you want.</text></comment>