jamesgresql

This is our old pitch, we have our own vector data-type in our main index in beta.

pg_search does both vector (this) and full-text (bm25) in a single index.

ParadeDB'er here: We are really hoping this can turn into a back and forth, making both of our products better.

ParadeDB built a benchmark runner to make experimentation easy. This post looks at a real example over three iterations (with wildly different results).

We (ParadeDB) recently started building out our benchmarking infrastructure for cross-backend comparisons.

Rather than taking the usual path of bundling a workload and execution into one neat package, we decided to build a reusable database benchmark runner based on grafana/k6 first.

This is great, no more lost terminal screens!

"If I had looked at the lexical search and BM25 space in 2016, I would have said it was solved, and that catching up would be nearly impossible."

This interview with Tantivy creator Paul Masurel looks at how wrong I would have been; discussing challenging solved domains, open-source competition done right, and why long-fermented frustration is an underrated driver.

Yeah I get that, I threw caution to the wind and did it (which I would normally never dO)

I have no affiliation with this product other than being a happy user, but man is it good for finding out exactly why and when your wifi is slow.

Best feature for me being was being able to detect intermittent jitter to my gateway. I never managed to catch this with speed-tests alone.

This is a no-nonsense walkthrough of doing hybrid search inside Postgres without spinning up a separate search service.

A few takeaway: - Postgres’s native `tsvector/ts_rank` stuff works ok for basic text matching, but it doesn’t account for global term frequency like BM25 does , so rankings can feel “flat” or noisy as soon as you go beyond simple queries (it's also slow). - Using a BM25 index (via extensions like `pg_search`) actually gives you relevance scores similar to what you’d expect out of modern search engines, and you can use stemmers/tokenization directly in SQL. BM25 is the star of this story. - Vector search fills in the semantic gaps (so “database optimization” isn’t limited to exact keywords), but you still don’t want to throw out lexical relevance. The trick is making it additive, not just adding scores together. - RRF (Reciprocal Rank Fusion) is a neat practical tool here. It sidesteps trying to normalize totally different scoring systems by just focusing on rank positions.

If you’re building anything where relevance matters (docs, product search, help articles) having BM25 + vector makes a big difference over vanilla FTS + embeddings alone. It also keeps everything in Postgres, which simplifies consistency/ops compared to an external search cluster.

I know it sounds obvious, but some people are pretty determined to us it that way!

Hey HN! Author here. We added faceted search capabilities to our `pg_search` extension for Postgres, which is built on Tantivy (Rust's answer to Lucene). This brings Elasticsearch-style faceting directly into Postgres with a 14x performance improvement over a CTE based approach by performing facet aggregations in a single BM25 index pass and making use of our columnar store.

You get the same faceting features you'd expect from a dedicated search engine while maintaining full ACID compliance. Happy to answer technical questions about the implementation!

Haha, I like “good old tokenization”

Amazing, will have a read!

Chinese, Japanese, Korean etc.. don’t work like this either.

However, even though the approach is “old fashioned” it’s still widely used for English. I’m not sure there is a universal approach that semantic search could use that would be both fast and accurate?

At the end of the day people choose a tokenizer that matches their language.

I will update the article to make all this clearer though!

100%, maybe we should do a follow up on other types of tokenization.

Hello HN, author here. It seems like everyone is talking about 'hybrid search' (lexical/BM25 + semantic/vector) these days, so I wanted to show how it's possible (and fully customizable) using reciprocal rank fusion in SQL.

The original title of this post was "When Tokenization Becomes Token", but nobody got it.

I'm curious, after reading this article how many people can tell me why that title would have been great?

(also I'd love feedback on the interactive components, I think they came out well!)

Author here — you beat me to it!

Hi everyone A lot of you will probably see the title of this post and immediately think “of course, just use the right tool for the job.”

But for those who don’t … here's a thing for you.

I’d really love to hear from both sides:

- Folks who’ve been burned by using Elastic as a primary datastore.

- Folks who haven’t — and can make the case for why it works just fine. (I know some of you are out there!)

Not the case!

Tiger here, let's go!

Hi HN! I've been benchmarking again, this time looking at all the permutations of COPY and INSERT in Postgres.

Let me know what you think.

Hi HN! If you're interested in PostgreSQL or database performance here's a short benchmark I did looking into the seemingly magical performance gain you can get by INSERTing unnested arrays rather than VALUES tuples in Postgres.

Let me know if you have any questions or suggestions for next articles.

Hi HN!

I wrote this article comparing TimescaleDB's SkipScan feature to vanilla Postgres performance for DISTINCT queries (get me the last row for all IDs) while a 200K rows per second ingest was happening.

I'm going to be writing more of these smaller performance pieces (sometimes Timescale related, sometimes Postgres related) - I'd love to hear some suggestions (especially around PG performance) from the HN community

Our Insights product at Timescale recently ticked over 1 petabyte of storage, 100 trillion metrics stored, 800 billion metrics per day.

A lot of the data is stored using Timescale's Tiering feature, but all that data is still ingested into Postgres and queryable as normal.

It’s amazing what Postgres can do if you architect your solution well.

Great comments!

This is exactly where we see ourselves contributing: both making pgvector faster and more efficient through pgvectorscale, and working to make the AI on Postgres developer experience first class.

Super excited about this launch, happy to answer any questions (or jump into our Discord for more)

The pgvectorscale repo is at: https://github.com/timescale/pgvectorscale

(Author here) Oh for sure! This is specifically about databases, databases can't do it all (unless you use Omnigres I suppose?)

(Author here!) I'd compare performance to what you need, not to other technology.

But also, point taken. The article this comment thread describes also needs to be written.

Author here, this is obviously a high level post! There are many, many posts about how Postgres with different extensions can get you different things.

I didn't want to go down that path for this article because I didn't want it to end up as a sales pitch. The article you describe needs to be written, but it's a follow-up in my mind (and much more technical, for a slightly different audience).