Second that recommendation, and I think that podcast would particularly as appeal to a lot of the HN crowd. I listened from the beginning until the early/mid 20th century philosophers and understood so much more about my own perspective on the world as a result.

I see a lot of back and forth about postgres' suitability as a queuing system. I wonder if there's a couple of separable problems here. Postgres backed queues - even very scalable ones - might work well for background jobs in a monolithic app backed by a single DB. Things like backgrounding sending an email etc.

But usually when I reach for a queuing system, it's because I want to decouple a part of the architecture. And in that case, it's probably better to use a dedicated queueing system instead of postgres.

I wonder if the two cases are conflated in a lot of online discussion.

We are very heavily using Postgres as a queuing system in production for many years already, not just some quiet background tasks but with millions of tasks in the queue at any given moment. I have yet so see any issues with that so I'm always a bit suspicious when people say they had to reach for something else unless you are at a crazy scale.

I know it's very hard to compare workloads, but famous recent example: https://openai.com/index/scaling-postgresql/

> It may sound surprising that a single-primary architecture can meet the demands of OpenAI’s scale; however, making this work in practice isn’t simple.

That post is about how Postgres doesn't scale for write-heavy workloads and that they had to move those workloads to Cosmos DB. For the rest of the remaining mostly-read workload they have a single primary with 50 read replicas.

The point is that Postgres scales a very long way. Once you arrive at OpenAI / ChatGPT scale there's no shame in reaching for a dedicated queuing system.

> scales a very long way

This ignores the fine print. It scales a very long way under specific circumstances with specific workloads. The more write-heavy your workload the less eloquently Postgres scales.

For OpenAI's use case you could swap Postgres with MySQL and it would scale just as well.

We are talking about Postgres as a queue here, which is heavy on tiny writes, reads and churning tables. The point is just that a RDMS like Postgres scales very far as a queue, it’s not a fight if Postgres or MySQL.

Nobody is arguing for using it for everything and forever but for most company sizes it’s perfectly fine to not reach for a dedicated queuing tool if you already have PG running.

> on tiny writes

Postgres doesn't do "tiny writes" - it writes whole pages multiple times on every update even if you're only changing 4 bytes, combined with even more writes later on when vacuuming tables. This is one of the reasons why the historical advice was to not build high-volume queues on top of Postgres and why "oh look another post about queues on Postgres" keeps soliciting comments like this.

If your DB is write heavy, tune it for writes...

You can't tune your way out of this constraint. The heap table and MVCC implementation put a hard ceiling on what can be accomplished without reaching for another tool.

In the UK, pretty much zero. Nobody ever leaves their windows down when they leave their car.

Indeed. Real life hacks are beginning to sound like Neuromancer.

It's like Mega Man Battle Network now. AIs jack in and battle it out!

It says something about the state of the world that I was genuinely uncertain whether this was actually a joke right until the last paragraph.

Very well done.

I too was nervous until I clicked through and had a read.

That's interesting and actually the opposite of mine. I wonder if it's stack or methodology dependant? For reference I'm usually using cursor and opus4.6 and for a bigger piece of work:

- Start in ask mode - "I'm planning on doing X to achieve Y; are there any alternative approaches? What problems might I run into?"

- Chat for a bit and get the high level approach, switch to plan mode and ask for a nicely formatted plan

- What's kicked out is already in the rough shape of the discussion so far, so it's a case of following a nicely formatted doc through and highlighting sections of text and asking for clarification or changes

- Hitting "build" and then reviewing what's been done

For a new service I might spend an hour in ask/plan mode - but then it gets 95% of the build itself right first time.

Do you do the same with different results, or is there a different stack/methodology you go through?

I can't speak to this particular case, but most of the delay is likely to be organisational rather than technical at this kind of scale.

Don't think about how hard it is to migrate a VM to a new provider. Think about how hard it is to:

* Get procurement to sign off on a new vendor

* Guarantee that your ISO compliance standards can be met under the new regime

* Make sure that GDPR requirements are met during any data transfer process to the satisfaction of your legal team

* Get the old infrastructure team and the new infrastructure team coordinated enough to be able to plan a migration without downtime

* Mollify the consultants that the CEO's friend said he should hire

* Analyse the migration plan to death to derisk it while at the same time be unable to actually evaluate it small scale due to the points above

Don't forget any relevant training for employees (e.x. for things like 'how to connect to a virtual desktop'). That can add up in some cases.

How could that possibly, ever have made it through. Every single API for every single service didn't check the JWT?

It started as internal service where you need to be connected with a VPN so why bother with security.

Vibe coding? Just have LLM make it and then press merge?

Eh, ironically this is an easy mistake to make for a human especially around how middleware is handled in express or other nodejs libraries, it's the reason why so so many of the vulnerabilities come from node based apps. Python has similar footguns as well with undefined objects failing open. Typescript has somewhat mitigated these for node, but there is no real fix for python other than skipping libraries that allow failing open.

Yeah I see this type of crap often honestly, especially at big companies.

I think the specific case of having a long conversation with an agent about what you're trying to achieve and why, and then have it update a README or a skill based on that conversation is a useful thing to do. Captured the context of the conversation without having to essentially write the same thing again.

That's usually because the system that runs those things is independent of the timing of the main game loop. And then when someone finally gets around to implementing the pause screen, they still run even with the main game time stopped. And you look at it and think "eh, you know what - looks cool - we'll leave it".