I don't think the readership of HN leans RW, but the commentary and moderation does, largely due to the fact that RW commentators are quick to flag views they disagree with, in contravention of the stated moderation standards, while "normal people" can't be bothered to engage with this kind of platform, and the moderation team is content to let this dynamic persist. Witness the flagging on this very article as an example.

* Metrics, monitoring, alarming on depth, message age

* Autoscaling on your custom metrics

* Managing retries, dead lettering, backoff

* Managing the DB workload: it's update-heavy and may easily be more intensive than the rest of your app. You may need to repeatedly scale your tiny, startup-scale DB, causing customer disruptions, because of your homemade queue.

The arguments for it are either avoidance of lock-in, or the hand-wavy one in this article/many comments: "we're a small startup, we need to minimize complexity, and make things as simple as possible, maintenance will kill us!".

Lock-in makes sense (though other queue alternatives should still be considered), but the latter argument gets used to justify all kinds of harebrained, superficially-simple but actually-complicated engineering schemes. I generally put the PG skip locked approach in that bucket, particularly when the alternative on hand is Pubsub or SQS. If it's between a Postgres table and ActiveMQ I might feel more conflicted.

I agree with the original commenter about ANY as well: using IN for dynamic lists of parameters makes viewing useful information in e.g pg_stat_statements impossible, though it's possible there's been some recent work around normalizing these.

Example: https://scottlocklin.wordpress.com/2021/11/20/us-public-heal...

If your natural key is bigger than the appropriately sized surrogate key, and it will be referenced across the database in other tables, the overhead of referencing it everywhere (and indexing it in those places -- potentially in much larger tables) can easily outweigh the overhead of the extra bytes on the original table.

Additionally, surrogate keys can realize much better performance WRT cache locality.

There is nothing about what you are describing that is different from the behavior you'd get from a regular insert or update. If two transactions conflict, a rollback will occur. That isn't violating atomicity. In fact, it is the way by which atomicity is guaranteed.

The behavior of sequence values getting incremented and not committed, resulting in gaps in the sequence, is a separate matter, not specific to Postgres or to upsert.

You can push back on this a little - for instance maybe you consider an array-valued attribute to be enough like a relation to argue array-valued attributes violate 1NF. But if you do that you must also explain what makes arrays different from strings, since strings are pretty similar to arrays of characters and can be treated the same way in most respects (for instance characters in a string can be addressed by index or split into substrings).

ON CONFLICT DO UPDATE guarantees an atomic INSERT or UPDATE outcome; provided there is no independent error, one of those two outcomes is guaranteed, even under high concurrency. This is also known as UPSERT — “UPDATE or INSERT”.

https://www.postgresql.org/docs/current/sql-insert.html

What are you referring to?

Both strategies have tradeoffs, both have produced successes and failures, and choice of approach seems (obviously) too specific to a given context and application for general advice to apply.

In general a user doesn't want to find "page 3", they are looking for a record that has certain characteristics. They shouldn't need to think about pages, just search terms.

On the more general question of whether stimulants are necessary for work... my experience is this idea is bizarre and out of line with professional programmers more than a few years out of university (where desperate students take adderall to cram for exams, and thus come into the workforce with that somewhat normalized).

Once a few years out you will have so many employment options that the idea of risking your heart health for a programming job will seem asinine... like biking to school without a helmet.

California's actions seems pretty consistent with this to me: https://storage.courtlistener.com/recap/gov.uscourts.cand.31...