dalberto

> Postgres as it's built now lacks any semblence of extensibility

PostGIS. pgvector. TimescaleDB. Citus. pg_cron. pgmq. Apache AGE. ParadeDB. hstore. plv8. postgres_fdw. pg_partman. pg_stat_statements...

The extension API is the thing making your thesis possible. Rewriting it away would mean deleting the exact feature you're asking for.

A benchmark without Opus 4.6/4.7 feels incomplete.

I generally agree that one database instance is ideal, but there are other reasons why Postgres everywhere is advantageous, even across multiple instances:

- Expertise: it's just SQL for the most part - Ecosystem: same ORM, same connection pooler - Portability: all major clouds have managed Postgres

I'd gladly take multiple Postgres instances even if I lose cross-database joins.

Haven't deployed production Java in years, so I won't speak to it. However, even with Go's static binaries, I'd like to leverage the same build and deploy process as other stacks. With Docker a Go service is no different than a Python service. With Docker, I use the same build tool, instrument health checks similarly, etc.

Standardization is major. Every major cloud has one (and often several) container orchestration services, so standardization naturally leads to portability. No lock-in. From my local to the cloud.

Even when running things in their own box, I likely want to isolate things from one another.

For example, different Python apps using different Python versions. venvs are nice but incomplete; you may end up using libraries with system dependencies.

Hard disagree. I've used Docker predominantly in monoliths, and it has served me well. Before that I used VMs (via Vagrant). Docker certainly makes microservices more tenable because of the lower overhead, but the core tenets of reproducibility and isolation are useful regardless of architecture.

That makes sense, though a bit disappointing. One hope of using Postgres as a task queue is simplifying your overall stack. Having to host RabbitMQ partially defeats that. I'll stay tuned for the Postgres-backed messaging!

I'm super interested in a Postgres-only task queue, but I'm still unclear from your post whether the only broker dependency is PostgreSQL. You mention working towards getting rid of the RabbitMQ dependency but the existence of RabbitMQ in your stack is dissonant with the statement 'a conviction that PostgreSQL is the right choice for a task queue'. In my mind, if you are using Postgres as a queue, I'm not sure why you'd also have RabbitMQ.