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.

Async django is not for the faint of heart, but it's definitely possible in 2025.

I recently wrote about issues debugging this stack[1], but now I feel very comfortable operating async-first.

[1] https://blendingbits.io/p/i-used-claude-code-to-debug-a-nigh...

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.

Consider: https://github.com/musistudio/claude-code-router

or even: https://github.com/sst/opencode

Not affiliated with either one of these, but they look promising.

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.

I'm curious if this supports coroutines at tasks in Python. It's especially useful for genAI, and legacy queues (namely Celery) are lacking in this regard.

It would help to see a mapping of Celery to Hatchet as examples. The current examples require you to understand (and buy into) Hatchet's model, but that's hard to do without understanding how it compares to existing solutions.

Looks very cool, planning on giving it a try. Also appreciate transparency around pricing.

That's fair, a lot of these features do not require a beefy processor. I think the value lies in the AW being a full-featured platform. Its processor is overkill for the lightest use-cases like remote shutter, but for others it's nice having a smartphone-like experience.

Case in point: Maps are full featured, it's not just about traffic, it's also about points of interest, supporting different modalities (crucially, public transit), and generally feeling like the full maps experience.

Like any other platform, 3rd party apps are nice for niches that the manufacturers do not serve, or do not serve well. For example, lifting apps make it super easy to log sets, reps, rest, etc; useful data the core experience does not offer.

As mentioned earlier, I think there's room for both. I'm actually not opposed to sporting a Garmin for endurance sports, where battery life is king :)

Some of the features I use on my Apple Watch all the time:

- Turn-by-turn directions with full-featured map apps.

- Stream and control podcasts.

- Ditto Audiobooks.

- As a remote shutter for my phone camera (eg group selfies).

- Dedicated 3rd party fitness apps (Alltrails, strength training apps).

I understand all this functionality is not everyone's cup of tea, but there's clearly a market for it.

Offtopic: I find a lot of the langchain hate is misplaced and misguided. Sure, if you want to ship a weekend project using the LLM APIs directly is probably fine. But I've gotten a lot of use out of Langchain's abstractions on real-world projects that evolve quickly over time. At a minimum, it provides a common language for building LLM applications.

Some valid criticisms: (1) the learning curve is steep (2) the APIs and docs are volatile (though to be expected).

This reminds me of the old Django vs Flask debate. Sure, Flask is easy to get started with, but over time you end up building an undocumented, untested Django.

For hybrid search

Any plans to support sparse vectors?

Thanks, I'm a sucker for word play!