Stu Hood
@stuhood.sh
Working on transactional, Elastic-quality search for Postgres at https://www.paradedb.com/ - 日本語を勉強しています
Passed the JLPT N5! 🎉
やった！
やった！
January 30, 2026 at 1:15 AM
Passed the JLPT N5! 🎉
やった！
やった！
New (to me) coding agent use case: shrinking bug repros involving huge queries.
Essentially: "this query reproduces a bug: please binary search to shrink it."
Essentially: "this query reproduces a bug: please binary search to shrink it."
January 22, 2026 at 6:55 PM
New (to me) coding agent use case: shrinking bug repros involving huge queries.
Essentially: "this query reproduces a bug: please binary search to shrink it."
Essentially: "this query reproduces a bug: please binary search to shrink it."
Reposted by Stu Hood
High-quality search is more than keyword matching. Personalization is what takes search from good to great.
We're investing a lot in building the "unified retrieval stack" for Postgres this year. Expect lots of announcements.
For now, here's how to build personalization today.
We're investing a lot in building the "unified retrieval stack" for Postgres this year. Expect lots of announcements.
For now, here's how to build personalization today.
Ankit (ex-Instacart) shows us how to build personalized search entirely inside PostgreSQL.
A search for “king” could mean LOTR: Return of the King or The King’s Speech.
To fix that:
• Retrieve with BM25
• Rerank with embeddings + cosine similarity
www.paradedb.com/blog/persona...
A search for “king” could mean LOTR: Return of the King or The King’s Speech.
To fix that:
• Retrieve with BM25
• Rerank with embeddings + cosine similarity
www.paradedb.com/blog/persona...
Retrieve and Rerank: Personalized Search Without Leaving Postgres
Build a production-grade personalized search engine entirely within Postgres using BM25 retrieval and vector-based reranking, no external infrastructure required.
www.paradedb.com
January 22, 2026 at 5:57 PM
High-quality search is more than keyword matching. Personalization is what takes search from good to great.
We're investing a lot in building the "unified retrieval stack" for Postgres this year. Expect lots of announcements.
For now, here's how to build personalization today.
We're investing a lot in building the "unified retrieval stack" for Postgres this year. Expect lots of announcements.
For now, here's how to build personalization today.
Reposted by Stu Hood
Apache DataFusion meetup in San Francisco: luma.com/p7r6fp2z Thursday, February 19. We are looking for more speakers and attendees!
San Francisco Apache DataFusion Meetup · Luma
Join us for an evening of talks and community discussion about Apache DataFusion and its growing role in modern data infrastructure. This year’s meetup will…
luma.com
January 17, 2026 at 11:17 AM
Apache DataFusion meetup in San Francisco: luma.com/p7r6fp2z Thursday, February 19. We are looking for more speakers and attendees!
Reposted by Stu Hood
As part of our v0.20.0 release late last year we did a lot of work on increasing write throughput.
Adding any index to a Postgres table trades off write speed for read speed, and BM25 indexes aren't any exception.
So we set out to make things better ....
www.paradedb.com/blog/increas...
Adding any index to a Postgres table trades off write speed for read speed, and BM25 indexes aren't any exception.
So we set out to make things better ....
www.paradedb.com/blog/increas...
How We Made Writes 10x Faster for Search
How ParadeDB achieved 10x improved write throughput through searchable buffers, background merging, and handling Postgres HOT chains.
www.paradedb.com
January 14, 2026 at 8:44 PM
As part of our v0.20.0 release late last year we did a lot of work on increasing write throughput.
Adding any index to a Postgres table trades off write speed for read speed, and BM25 indexes aren't any exception.
So we set out to make things better ....
www.paradedb.com/blog/increas...
Adding any index to a Postgres table trades off write speed for read speed, and BM25 indexes aren't any exception.
So we set out to make things better ....
www.paradedb.com/blog/increas...
Reposted by Stu Hood
The #tokioconf speakers and talks just got posted: www.tokioconf.com Ticket sales are open! Since it is our first conference, it is hard to estimate how many people will come. We're starting conservative, only 200 tickets right now.
TokioConf 2026 | Be a Part of Tokio's Official Conference!
Join 300+ developers at the inaugural TokioConf 2026 to exchange ideas, learn from one another, and explore the future of async Rust. Hosted by the Tokio Project
www.tokioconf.com
January 8, 2026 at 11:48 PM
The #tokioconf speakers and talks just got posted: www.tokioconf.com Ticket sales are open! Since it is our first conference, it is hard to estimate how many people will come. We're starting conservative, only 200 tickets right now.
I'm very excited about the work that we did on this: it allows for an extremely common full text search use case via a natural blend of fully compliant SQL syntax, with faceted aggregates that are familiar to full text search users. And it's fast! www.paradedb.com/blog/faceting
14x Faster Faceted Search in PostgreSQL with ParadeDB
Introducing faceted search in ParadeDB - bringing the power of search engine faceting to PostgreSQL with single-query aggregations.
www.paradedb.com
December 10, 2025 at 10:20 PM
I'm very excited about the work that we did on this: it allows for an extremely common full text search use case via a natural blend of fully compliant SQL syntax, with faceted aggregates that are familiar to full text search users. And it's fast! www.paradedb.com/blog/faceting
Reposted by Stu Hood
Faceting looks simple, it's just counts next to search results right? But making it fast and ergonomic is harder than it seems.
We just shipped native faceting in ParadeDB: it runs inside Postgres, in a index single pass, and is 14× faster over large result sets👇
www.paradedb.com/blog/faceting
We just shipped native faceting in ParadeDB: it runs inside Postgres, in a index single pass, and is 14× faster over large result sets👇
www.paradedb.com/blog/faceting
14x Faster Faceted Search in PostgreSQL with ParadeDB
Introducing faceted search in ParadeDB - bringing the power of search engine faceting to PostgreSQL with single-query aggregations.
www.paradedb.com
December 10, 2025 at 1:26 AM
Faceting looks simple, it's just counts next to search results right? But making it fast and ergonomic is harder than it seems.
We just shipped native faceting in ParadeDB: it runs inside Postgres, in a index single pass, and is 14× faster over large result sets👇
www.paradedb.com/blog/faceting
We just shipped native faceting in ParadeDB: it runs inside Postgres, in a index single pass, and is 14× faster over large result sets👇
www.paradedb.com/blog/faceting
Reposted by Stu Hood
We've shown you parts of our V2 SQL API over the last month, but here's a full post looking at everything you can do with it.
Check out the side by side of the CREATE TABLE for old and new APIs, it's so much better ❤️.
www.paradedb.com/blog/v2api
Check out the side by side of the CREATE TABLE for old and new APIs, it's so much better ❤️.
www.paradedb.com/blog/v2api
Deep Dive into ParadeDB's v2 API: The Future of SQL Search
Explore ParadeDB's v2 API that eliminates schema duplication, simplifies tokenization, and provides transparent search operators for intuitive SQL-based full-text search.
www.paradedb.com
December 4, 2025 at 10:12 PM
We've shown you parts of our V2 SQL API over the last month, but here's a full post looking at everything you can do with it.
Check out the side by side of the CREATE TABLE for old and new APIs, it's so much better ❤️.
www.paradedb.com/blog/v2api
Check out the side by side of the CREATE TABLE for old and new APIs, it's so much better ❤️.
www.paradedb.com/blog/v2api
The Nakasendo Trail between Magome (馬籠宿) and Tsumago (妻籠宿) in the Kiso Valley, Nagano.
November 25, 2025 at 5:25 AM
The Nakasendo Trail between Magome (馬籠宿) and Tsumago (妻籠宿) in the Kiso Valley, Nagano.
Reposted by Stu Hood
November 24, 2025 at 12:06 AM
Reposted by Stu Hood
What would that look like when you use a variable twice in a closure? Two `move` calls, or an error suggesting that it can only be moved once?
November 22, 2025 at 5:21 AM
What would that look like when you use a variable twice in a closure? Two `move` calls, or an error suggesting that it can only be moved once?
Lovely. And then once found, it's reproducible? Does adding additional debug information break the repro?
October 23, 2025 at 7:26 PM
Lovely. And then once found, it's reproducible? Does adding additional debug information break the repro?
What flavor of stuff are you finding?
October 23, 2025 at 7:05 PM
What flavor of stuff are you finding?
Reposted by Stu Hood
Almost like we founded the entire country on opposing this exact sentence.
October 15, 2025 at 2:30 PM
Almost like we founded the entire country on opposing this exact sentence.
I think that they've done such a good job with the software that I don't miss Android Auto (supporting CarPlay alone gets you 58% of the US market and leaves out 41%). As long as they continue investing to stay ahead, it's the right decision, imo.
October 6, 2025 at 4:53 PM
I think that they've done such a good job with the software that I don't miss Android Auto (supporting CarPlay alone gets you 58% of the US market and leaves out 41%). As long as they continue investing to stay ahead, it's the right decision, imo.
I will be watching this! I don't care!
[UCC] EJAE, Audrey Nuna, and Rei Ami from 'K-Pop Demon Hunters' to perform "Golden" on 'Tonight Show' www.allkpop.com/article/2025...
EJAE, Audrey Nuna, and Rei Ami from 'K-Pop Demon Hunters' to perform "Golden" on 'Tonight Show'
Get ready, because HUNTR/X is about to take the spotlight and show you how it’s done, done, done!The powerful trio of EJAE, Audrey Nuna, and R…
www.allkpop.com
October 3, 2025 at 9:40 PM
I will be watching this! I don't care!
Needs something like Community Notes to help deal with misinformation. www.lesswrong.com/posts/sx9wTy...
September 26, 2025 at 4:00 AM
Needs something like Community Notes to help deal with misinformation. www.lesswrong.com/posts/sx9wTy...
But yea, lots of that scaling is premature, so! 😅
September 20, 2025 at 8:52 PM
But yea, lots of that scaling is premature, so! 😅
If the data that is going into the calculation is within the same Postgres instance, then transactional boundaries are preserved... if it's not, and you're making network calls, then totally. At scale (either for team boundaries or performance) personalization data is likely to be living elsewhere.
September 20, 2025 at 8:51 PM
If the data that is going into the calculation is within the same Postgres instance, then transactional boundaries are preserved... if it's not, and you're making network calls, then totally. At scale (either for team boundaries or performance) personalization data is likely to be living elsewhere.
I like these buckets, but one exception here is when ordering by recency: immediately after creating something, regardless of result size, you expect to be able to find it in time order.
September 20, 2025 at 8:30 PM
I like these buckets, but one exception here is when ordering by recency: immediately after creating something, regardless of result size, you expect to be able to find it in time order.
We don't yet, but I suspect that we'll support re-ranking directly in ParadeDB. Elastic has a simple DSL for some re-ranking use cases: for us, the natural fit would be arbitrary (PL)SQL.
Rust extensions are also easier than ever to build: defining a fast(er) UDF to compute a score would work too.
Rust extensions are also easier than ever to build: defining a fast(er) UDF to compute a score would work too.
September 20, 2025 at 8:28 PM
We don't yet, but I suspect that we'll support re-ranking directly in ParadeDB. Elastic has a simple DSL for some re-ranking use cases: for us, the natural fit would be arbitrary (PL)SQL.
Rust extensions are also easier than ever to build: defining a fast(er) UDF to compute a score would work too.
Rust extensions are also easier than ever to build: defining a fast(er) UDF to compute a score would work too.