levkk

Kagi is amazing. Worth the subscription, 10 times over. I don't have to worry about sponsored search results, or slop from the "AI overview". High quality results, like Google used to be.

For a price of two cups of coffee.

This is nonsense. Tokio was built for I/O, not crunching numbers. Most programmers know to use spawn_blocking to crunch 10MB JSON, if needed.

Additionally, the proposed workload per thread model will be orders of magnitude slower than Tokio for I/O-bound workloads, which most applications are.

I think most tools, according to the UNIX philosophy, do one thing (and do it well). AI is a tool that does _a lot_ of things...to various degrees of success. While you can verify that the output of `sed` or `grep` is valid, you can't with 10k lines of code you have no context on (without _significant_ effort).

Same with Gimp, Firefox, and your terminal. Tools, all, do many easily verifiable things. AI isn't verifiable without an existing framework, and that's why it's so "good" at rewriting code from language A to language B, but not at zero-to-one building real world software.

Glad you like it. It was built to fix some of PgBouncers shortcomings that we ran into at Instacart many years ago, and to have a stronger foundation for scaling Postgres horizontally (that's sharding)!

Ouf. I don't know. I don't want to call you out without evidence -- I myself make benchmark claims all the time -- but 50% improvement in OLTP seems suspicious. I get that you used a standard benchmark, and I don't even know what it entails, but my spidey sense is going off. Perhaps, some trade off somewhere that won't make it to prod because it breaks MVCC -- and yes, I saw that it passes regression tests.

Just checking, is fsync on? :) Regression tests don't catch bad IO patterns afaik.

Anyway... sounds like a fun project to work on!

Pin the client temporarily. I'm assuming that our users know what they are doing. I could be wrong, but so far so good.

Yes. The plugin architecture supports this currently. That being said, you can use any number of sharding functions we support to do this too.

Thanks! We try to be very open and explicit about why we chose AGPL. Personally, I like it because it's an extension of GPL, which is a huge reason why I was able to self-teach programming. Just trying to give back.

Handling cursors is tough - they are very much session-level objects, so even if we, say, pinned your client while it uses that cursor, which would work, that would decrease the performance of connection pooling overall.

So, what's better, breaking your app initially so you know to remove that feature, or letting it work silently while the connection pool isn't 100% in transaction mode? Tough call.

I don't think so. Too much trouble. Caching is a really hard problem without context, and the context, typically, is app-specific.

From the strictest CAP theorem definition, that's correct, it is not. But, it's pretty close. I know that in the database world, that's not a good answer, but in practice, it will deliver the vast majority of messages, so maybe that's good enough? We'll see.

We show that it's possible to come close without breaking the DB or the app, but I suspect, it's not quite yet at the level you'd expect from a _durable_ work queue, e.g., Kafka. Not going to replace that one anytime soon.

Very cool. At first, I thought it was yet another LLM-generated demo, but no: original work of art. Super cool. Transpiling into C does seem easier than LLVM IR, and letting GCC optimize seems like this might actually work.

Excited to see the compiler implementation when it's out -- a lot to learn from.

I cancelled Claude. The harness is kinda broken, GPT 5.5 is good, and GLM 5.2/Deepseek is good too (with pi, especially). Just not worth the trouble. And I'm not going to pay two subscriptions.

CRUD apps don't usually delete in bulk. It's also hard to structure partitions in a way that doesn't wipe out months of important business data -- this is why teams often ETL their DB into Snowflake/ClickHouse and only then drop partitions. That makes it hard for the app to use that data again.

The better approach is either to change your storage engine (e.g. OrioleDB is working on adding the undo log to Pg), or to shard which distributes the vacuum load across multiple servers.

You can have multiple. All sharding is config-based, so no real-time synchronization is required.

This just checks if the package is installed, not if the installed version is infected. Presumably, if you (me...) haven't run `yay -Syu` in a while (months), we're fine, right? ...Right?

Goddamit, don't make me reinstall Arch, took me a week last time.

Update: archinstall rocks, back in business after like 15min.

I didn't realize there are _any_ managed providers of PgDog out there...do tell!

Awesome, glad it worked!

We also do that! But it's not well documented at the moment.

Thanks! Glad we made it relatively easy to migrate!

For sure. They should be used for "metadata"-style tables only. High throuput writes should be direct-to-shard.

Yeah good callout. We'll add rendezvous soon enough. Until then, being compatible with Postgres partitions has been advantageous -- while we build everything out, people were able to migrate to PgDog for the query routing layer while doing the resharding in Postgres.

Adding a sharding function in our architecture is relatively straightforward. We also support plugins which can control the flow (and direction) for queries, so our users can add their own (and they do!).

Not yet, but actively working on this as we speak.

fwiw, we support cross-shard transactions. They are not magic though, just good old 2pc and a bit of coordination.

Thanks!

This reminds me of college. We had to cite our own papers from prior semesters or risk getting kicked out for plagiarism. I don't miss those days :)

Thanks! Yup...to be expected. If you know, you know, and have the scars to prove it :)

Yup!

Two big ones:

1. Control plane to manage multi-node deployments; "works out of the box" experience to make PgDog easy to deploy and use

2. QoS (quality of service): automatically block bad queries from taking down the database

Last but not least, you get SLA-backed support from us (up to P0).

New features are broken down into two categories:

1. Sharding / running Postgres at scale: always open source.

2. Infra management / making it easy to run PgDog at scale: enterprise.

Good thing we support HA as well: https://docs.pgdog.dev/features/load-balancer/

Load balancer with health checks and failover, works out of the box. :) Battle-tested at this point too, so could be worth a look.