This has benchmark results for Postgres 18.0 using sysbench on a small server. Previous results for 18 rc1 are here.

tl;dr

• From 12.22 to 18.0
• there are no regressions larger than 2% but many improvements larger than 5%. Postgres continues to do a great job at avoiding regressions over time.
• From 17.6 to 18.0
• I continue to see small CPU regressions (1% or 2%) in Postgres 18 for short range queries on low-concurrency workloads. I see it for shorter but not for longer range queries so my guess is that this is new overhead in query execution setup or optimization. I hope to explain this.

This is my long-overdue trip report from last summer: July 10–11, 2024. We toured Ivy League campuses to help our rising senior son weigh his options, with our two daughters (our kids are four years apart each) tagging along for an early preview. Day one was Yale and Brown, followed by a night in New Jersey. Day two took us to Princeton and UPenn, then the long drive back to Buffalo. Of course we drove, that's how we roll.

Prelude

Lining up campus tours is its own sport. They are booked months in advance. Pro-tip: when your kid is born, call the colleges to reserve their campus visit. We lucked into two open slots, then hacked together a Python script to snipe cancellations and grabbed the other two. Not proud of this, but that's what it takes if you don't book months in advance.

The U.S. college admissions process is Byzantine. It is a weird mix of ritual and performance. There are entire books about how to write the college essay. I have plenty to say about the so-called holistic review process, but that's for another post. Back in Turkey, I just had to take a National University Entrance exam, and score very high to get placed in to a top university. That was also a broken system and was stressful, but at least there were no essays, no extracurriculars, no culture fit, no campus visits.

Here, though, the campus visit is part of the show. It is especially essential if you are considering to sign a binding early decision. Early decision boosts acceptance odds 3–4x. But it also locks you in. Our son didn't end up doing ED. His top choices didn't offer it, and he didn't want to burn his chances elsewhere.

Yale: Cathedrals and Low Energy

After six hours on the road we rolled into New Haven, paid for street parking, and joined the tour. Yale sits right in the city center, and the architecture hits you: gothic cathedrals and stone facades older than the country itself.

The name still carries weight. Even in Turkey, Yale was known through Yale locks, whose founder was a distant relative of the university's founder, Elihu Yale. The Yale programs are ranked high, the libraries are priceless, and the faculty-to-student ratio is great.

One stop in our campus tour was the Beinecke Library. Its marble-and-granite exterior filters light to protect fragile manuscripts. Our guide told us that in a fire, oxygen would be sucked out to save the books, even at the expense of people inside. Dying for the books is romantic, but the fact-check says this is a myth.

Yale also revealed the Ivy pattern we would see in other stops of our tour: Two years of mandatory dorms, no AP credit (just placement), and an abundance of pride in being  an Ivy.

We noted these as downsides at Yale. There is no strong pitch for undergraduate research. Some buildings are beautiful, others are just tired: 1960s concrete, no AC, worn interiors. On a hot day, it felt even worse. The CS building in particular was old, dark, and smelly. It looked like it was designed by someone who hated students.

Brown: The underrated Ivy

Ninety minutes later we were at Providence, attending the Brown campus tour at 3 pm.

Brown impressed us. The open curriculum gives students great freedom, for example, CS mixed with theater, neuroscience, and entrepreneurship. Research opportunities are emphasized from the start of the tour. Every student writes a senior thesis. Brown supports student research financially, and third- and fourth-year students can TA undergrad classes. Stay for a fifth year and you can leave with a combined MS. The culture is collaborative, not competitive. If you fail a class, it doesn't show up on your transcript. This way students are encouraged to take risks... or quit and be lazy, I don't know.

The campus sits on a hill overlooking Providence, close enough to the city. The faculty are strong, the vibe is progressive, and the students approachable. No Ivy airs here. Did you know that Emma Watson studied here? Our tour guide was excellent. Under his spell, my youngest daughter declared she would apply early decision to Brown when her time comes. Our son liked it too. He pointed out that Brown CS graduates earn the most one year out of college. The CS building is cramped and outdated, but still much better than Yale's. We all walked away charmed.

We drove to Jersey for a hotel. Our dinner was Dave's Hot Chicken. 

Princeton: The Old Country Club

Next morning: Princeton. It has a huge campus. We parked at the stadium, and took a shuttle to the welcome center.

Princeton is historic and prestigious. Einstein once taught here. Princeton still has very strong faculty and a lot of resources. Undergraduates do research for senior thesis. But our tour guide spent more time talking about dining clubs and traditions than academics. It felt hollow. Too polished, too self-satisfied. Brown had been about people. Princeton was about tradition and Ivy airs. Unlike Brown, Princeton does not offer an open curriculum or fifth-year MS. 

One odd scene was a busload of Chinese families arriving with luggage in tow, apparently right out of the airport. They dragged luggages across campus, straight into the tour. Princeton seems to have strong prestige in China.

UPenn: Philly Hustle

From Princeton, it was a short drive to Philadelphia. But what a view change. UPenn is right under the Philly downtown skyscrapers scenery.

UPenn struck us as hands-on and pragmatic. In your first year you get a writing course. In your 3rd and 4th years you write research reports and senior thesis. Double majors are allowed, minors too. The Wharton School of Business looms large: alumni include both Donald Trump and Jho Low, the billion-dollar corruption guy. What are they teaching there?

Food trucks lined the campus streets, serving better meals than many college dining halls. The lamb shawarma was awesome! While UPenn is dead in the center of downtown, they still have compulsory two years dorm stay like the other ivies. Our younger daughter adored the tour guide, adopted her as an older sister, and by the end of the tour, declared UPenn as her new top choice.

Closing

So our ranking is:

• Brown
• UPenn
• Princeton
• Yale

Brown feels underrated within the Ivies. The Ivies as a whole, though, are overrated. Colleges in general are overrated. These schools still coast on prestige built centuries ago. But the world has changed drastically. If they want to matter in the age of the internet and AI, they will need to adapt.

Previously, I demonstrated MongoDB text search scoring with a simple example, creating a dynamic index without specifying fields explicitly. You might be curious about what data is actually stored in such an index. Let's delve into the specifics. Unlike regular MongoDB collections and indexes, which use WiredTiger for storage, search indexes leverage Lucene technology. We can inspect these indexes using Luke, the Lucene Toolbox GUI tool.

Set up a lab

I started an Atlas local deployment to get a container for my lab:

# download Atlas CLI if you don't have it. Here it is for my Mac:
wget https://www.mongodb.com/try/download/atlascli
unzip mongodb-atlas-cli_1.43.0_macos_arm64.zip

# start a container
bin/atlas deployments setup  atlas --type local --port 27017 --force

Sample data

I connected with mongosh and created a collection, and a search index, like in previous post:

mongosh --eval '

db.articles.deleteMany({});

db.articles.insertMany([
 { description : "🍏 🍌 🍊" },                // short, 1 🍏
 { description : "🍎 🍌 🍊" },                // short, 1 🍎
 { description : "🍎 🍌 🍊 🍎" },             // larger, 2 🍎
 { description : "🍎 🍌 🍊 🍊 🍊" },          // larger, 1 🍎
 { description : "🍎 🍌 🍊 🌴 🫐 🍈 🍇 🌰" },  // large, 1 🍎
 { description : "🍎 🍎 🍎 🍎 🍎 🍎" },       // large, 6 🍎
 { description : "🍎 🍌" },                 // very short, 1 🍎
 { description : "🍌 🍊 🌴 🫐 🍈 🍇 🌰 🍎" },  // large, 1 🍎
 { description : "🍎 🍎 🍌 🍌 🍌" },          // shorter, 2 🍎
]);

db.articles.createSearchIndex("default",
  { mappings: { dynamic: true } }
);

'

Get Lucene indexes

While MongoDB collections and secondary indexes are stored by the WiredTiger storage engine (by default in /data/db directory), the text search indexes use Lucene in a mongot process (with files stored by default in /data/mongot). I copied it to my laptop:

docker cp atlas:/data/mongot ./mongot_copy
cd mongot_copy

One file is easy to read, as it is in JSON format, and it is the metadata listing the search indexes, with their MongoDB configuration:

cat configJournal.json | jq

{
  "version": 1,
  "stagedIndexes": [],
  "indexes": [
    {
      "index": {
        "indexID": "68d0588abf7ab96dd26277b1",
        "name": "default",
        "database": "test",
        "lastObservedCollectionName": "articles",
        "collectionUUID": "a18b587d-a380-4067-95aa-d0e9d4871b64",
        "numPartitions": 1,
        "mappings": {
          "dynamic": true,
          "fields": {}
        },
        "indexFeatureVersion": 4
      },
      "analyzers": [],
      "generation": {
        "userVersion": 0,
        "formatVersion": 6
      }
    }
  ],
  "deletedIndexes": [],
  "stagedVectorIndexes": [],
  "vectorIndexes": [],
  "deletedVectorIndexes": []
}

The directory where Lucene files are stored has the IndexID in their names:

ls 68d0588abf7ab96dd26277b1*

_0.cfe _0.cfs _0.si
_1.cfe _1.cfs _1.si
_2.cfe _2.cfs _2.si
_3.cfe _3.cfs _3.si
_4.cfe _4.cfs _4.si
_5.cfe _5.cfs _5.si
_6.cfe _6.cfs _6.si
segments_2
write.lock

In a Lucene index, each .cfs/.cfe/.si set represents one immutable segment containing a snapshot of indexed data (with .cfs holding the actual data, .cfe its table of contents, and .si the segment’s metadata), and the segments_2 file is the global manifest that tracks all active segments so Lucene can search across them as one index.

Install and use Luke

I installed the Lucene binaries and started Luke:

wget https://dlcdn.apache.org/lucene/java/9.12.2/lucene-9.12.2.tgz
tar -zxvf lucene-9.12.2.tgz
lucene-9.12.2/bin/luke.sh

This starts the GUI asking for the index directory:

The "Overview" tab shows lots of information:

The field names are prefixed with the type. My description field was indexed as a string and named $type:string/description. There are 9 documents and 9 different terms:

The Lucene index keeps the overall frequency in order to apply Inverse Document Frequency (IDF). Here, 🍎 is present in 8 documents and 🍏 in one.

The "Document" tab lets us browse the documents and see what is indexed. For example, 🍏 is present in one document with { description: "🍏 🍌 🍊" }:

The flags IdfpoN-S mean that it is a fully indexed text field with docs, frequencies, positions, and offsets, with norms and stored values

The "Search" tab allows to run queries. For example, { $search: { text: { query: ["🍎", "🍏"], path: "description" }, index: "default" } } from my previous post is:

This is exactly what I got from MongoDB:

db.articles.aggregate([
  { $search: { text: { query: ["🍎", "🍏"], path: "description" }, index: "default" } },
  { $project: { _id: 0, score: { $meta: "searchScore" }, description: 1 } },
  { $sort: { score: -1 } }
]).forEach( i=> print(i.score.toFixed(3).padStart(5, " "),i.description) )

1.024 🍏 🍌 🍊
0.132 🍎 🍎 🍎 🍎 🍎 🍎
0.107 🍎 🍌 🍊 🍎
0.101 🍎 🍎 🍌 🍌 🍌
0.097 🍎 🍌
0.088 🍎 🍌 🍊
0.073 🍎 🍌 🍊 🍊 🍊
0.059 🍎 🍌 🍊 🌴 🫐 🍈 🍇 🌰
0.059 🍌 🍊 🌴 🫐 🍈 🍇 🌰 🍎

If you double-click on a document in the result, you can get the explanation of the score:

For example, the score of 🍏 🍌 🍊 is explained by:

1.0242119 sum of:
  1.0242119 weight($type:string/description:🍏 in 0) [BM25Similarity], result of:
    1.0242119 score(freq=1.0), computed as boost * idf * tf from:
      1.89712 idf, computed as log(1 + (N - n + 0.5) / (n + 0.5)) from:
        1 n, number of documents containing term
        9 N, total number of documents with field
      0.5398773 tf, computed as freq / (freq + k1 * (1 - b + b * dl / avgdl)) from:
        1.0 freq, occurrences of term within document
        1.2 k1, term saturation parameter
        0.75 b, length normalization parameter
        3.0 dl, length of field
        4.888889 avgdl, average length of field

The BM25 core formula is score = boost × idf × tf

IDF (Inverse Document Frequency) is idf = log(1 + (N - n + 0.5) / (n + 0.5)) where n is the number of documents containing 🍏 , so 1, and N is the total documents in the index for this field, so 9

TF (Term Frequency normalization) is tf = freq / ( freq + k1 × (1 - b + b × (dl / avgdl)) ) where freq is the term occurrences in this doc’s field, so 1, k1 is the term saturation parameter, which defaults to 1.2 in Lucene, b is the length normalization, which defaults to 0.75 in Lucene, dl is the document length, which is 3 tokens here, and avgdl is the average document length for this field in the segment, here 4.888889

Daily usage in MongoDB search also allows boosting via the query, which multiplies into the BM25 scoring formula (boost).

The "Analysis" tab helps explain how strings are tokenized and processed. For example, the standard analyzer explicitly recognized emojis:

Conclusion

MongoDB search indexes are designed to work optimally out of the box. In my earlier post, I relied entirely on default settings, dynamic mapping, and even replaced words with emojis — yet still got relevant, well-ranked results without extra tuning. If you want to go deeper and fine-tune your search behavior, or simply learn more about how it works, inspecting the underlying Lucene index can provide great insights. Since Atlas Search indexes are Lucerne-compatible, tools like Luke allow you to see exactly how your text is tokenized, stored, and scored — giving you full transparency into how queries match your documents.

Previously, I demonstrated MongoDB text search scoring with a simple example, creating a dynamic index without specifying fields explicitly. You might be curious about what data is actually stored in such an index. Let's delve into the specifics. Unlike regular MongoDB collections and indexes, which use WiredTiger for storage, search indexes leverage Lucene technology. We can inspect these indexes using Luke, the Lucene Toolbox GUI tool.

Set up a lab

I started a Atlas local deployment to get a container for my lab:

# download Atlas CLI if you don't have it. Here it is for my Mac:
wget https://www.mongodb.com/try/download/atlascli
unzip mongodb-atlas-cli_1.43.0_macos_arm64.zip

# start a container
bin/atlas deployments setup  atlas --type local --port 27017 --force

Sample data

I connected with mongosh and created a collection, and a search index, like in the previous post:

mongosh --eval '

db.articles.deleteMany({});

db.articles.insertMany([
 { description : "🍏 🍌 🍊" },                // short, 1 🍏
 { description : "🍎 🍌 🍊" },                // short, 1 🍎
 { description : "🍎 🍌 🍊 🍎" },             // larger, 2 🍎
 { description : "🍎 🍌 🍊 🍊 🍊" },          // larger, 1 🍎
 { description : "🍎 🍌 🍊 🌴 🫐 🍈 🍇 🌰" },  // large, 1 🍎
 { description : "🍎 🍎 🍎 🍎 🍎 🍎" },       // large, 6 🍎
 { description : "🍎 🍌" },                 // very short, 1 🍎
 { description : "🍌 🍊 🌴 🫐 🍈 🍇 🌰 🍎" },  // large, 1 🍎
 { description : "🍎 🍎 🍌 🍌 🍌" },          // shorter, 2 🍎
]);

db.articles.createSearchIndex("default",
  { mappings: { dynamic: true } }
);

'

Get Lucene indexes

While MongoDB collections and secondary indexes are stored by the WiredTiger storage engine (by default, in the /data/db directory), the text search indexes use Lucene in a mongot process (with files stored by default in /data/mongot). I copied it to my laptop:

docker cp atlas:/data/mongot ./mongot_copy
cd mongot_copy

One file is easy to read, as it is in JSON format, and it is the metadata listing the search indexes, with their MongoDB configuration:

cat configJournal.json | jq

{
  "version": 1,
  "stagedIndexes": [],
  "indexes": [
    {
      "index": {
        "indexID": "68d0588abf7ab96dd26277b1",
        "name": "default",
        "database": "test",
        "lastObservedCollectionName": "articles",
        "collectionUUID": "a18b587d-a380-4067-95aa-d0e9d4871b64",
        "numPartitions": 1,
        "mappings": {
          "dynamic": true,
          "fields": {}
        },
        "indexFeatureVersion": 4
      },
      "analyzers": [],
      "generation": {
        "userVersion": 0,
        "formatVersion": 6
      }
    }
  ],
  "deletedIndexes": [],
  "stagedVectorIndexes": [],
  "vectorIndexes": [],
  "deletedVectorIndexes": []
}

The directory where Lucene files are stored has the IndexID in their names:

ls 68d0588abf7ab96dd26277b1*

_0.cfe _0.cfs _0.si
_1.cfe _1.cfs _1.si
_2.cfe _2.cfs _2.si
_3.cfe _3.cfs _3.si
_4.cfe _4.cfs _4.si
_5.cfe _5.cfs _5.si
_6.cfe _6.cfs _6.si
segments_2
write.lock

In a Lucene index, each .cfs/.cfe/.si set represents one immutable segment containing a snapshot of indexed data (with .cfs holding the actual data, .cfe its table of contents, and .si the segment’s metadata), and the segments_2 file is the global manifest that tracks all active segments so Lucene can search across them as one index.

Install and use Luke

I installed the Lucene binaries and started Luke:

wget https://dlcdn.apache.org/lucene/java/9.12.2/lucene-9.12.2.tgz
tar -zxvf lucene-9.12.2.tgz
lucene-9.12.2/bin/luke.sh

This starts the GUI asking for the index directory:

The "Overview" tab shows lots of information:

The field names are prefixed with the type. My description field was indexed as a string and named $type:string/description. There are nine documents and nine different terms:

The Lucene index keeps the overall frequency in order to apply inverse document frequency (IDF). Here, 🍎 is present in eight documents and 🍏 in one.

The "Document" tab lets us browse the documents and see what is indexed. For example, 🍏 is present in one document with { description: "🍏 🍌 🍊" }:

The flags IdfpoN-S mean that it is a fully indexed text field with docs, frequencies, positions, and offsets, with norms and stored values.

The "Search" tab allows us to run queries. For example, { $search: { text: { query: ["🍎", "🍏"], path: "description" }, index: "default" } } from my previous post is:

This is exactly what I got from MongoDB:

db.articles.aggregate([
  { $search: { text: { query: ["🍎", "🍏"], path: "description" }, index: "default" } },
  { $project: { _id: 0, score: { $meta: "searchScore" }, description: 1 } },
  { $sort: { score: -1 } }
]).forEach( i=> print(i.score.toFixed(3).padStart(5, " "),i.description) )

1.024 🍏 🍌 🍊
0.132 🍎 🍎 🍎 🍎 🍎 🍎
0.107 🍎 🍌 🍊 🍎
0.101 🍎 🍎 🍌 🍌 🍌
0.097 🍎 🍌
0.088 🍎 🍌 🍊
0.073 🍎 🍌 🍊 🍊 🍊
0.059 🍎 🍌 🍊 🌴 🫐 🍈 🍇 🌰
0.059 🍌 🍊 🌴 🫐 🍈 🍇 🌰 🍎

If you double-click on a document in the result, you can get the explanation of the score:

For example, the score of 🍏 🍌 🍊 is explained by:

1.0242119 sum of:
  1.0242119 weight($type:string/description:🍏 in 0) [BM25Similarity], result of:
    1.0242119 score(freq=1.0), computed as boost * idf * tf from:
      1.89712 idf, computed as log(1 + (N - n + 0.5) / (n + 0.5)) from:
        1 n, number of documents containing term
        9 N, total number of documents with field
      0.5398773 tf, computed as freq / (freq + k1 * (1 - b + b * dl / avgdl)) from:
        1.0 freq, occurrences of term within document
        1.2 k1, term saturation parameter
        0.75 b, length normalization parameter
        3.0 dl, length of field
        4.888889 avgdl, average length of field

The BM25 core formula is score = boost × idf × tf.

IDF is idf = log(1 + (N - n + 0.5) / (n + 0.5)) where n is the number of documents containing 🍏 , so 1, and N is the total documents in the index for this field, so 9.

TF is tf = freq / ( freq + k1 × (1 - b + b × (dl / avgdl)) ) where freq is the term occurrences in this doc’s field, so 1, k1 is the term saturation parameter, which defaults to 1.2 in Lucene, b is the length normalization, which defaults to 0.75 in Lucene, dl is the document length, which is three tokens here, and avgdl is the average document length for this field in the segment—here, 4.888889.

Daily usage in MongoDB search also allows boosting via the query, which multiplies into the BM25 scoring formula (boost).

The "Analysis" tab helps explain how strings are tokenized and processed. For example, the standard analyzer explicitly recognized emojis:

Finally, I inserted 500 documents with other fruits, like in the previous post, and the collection-wide term frequency has been updated:

The scores reflect the change:

The explanation of the new rank for 🍏 🍌 🍊 is:

3.2850468 sum of:
  3.2850468 weight($type:string/description:🍏 in 205) [BM25Similarity], result of:
    3.2850468 score(freq=1.0), computed as boost * idf * tf from:
      5.8289456 idf, computed as log(1 + (N - n + 0.5) / (n + 0.5)) from:
        1 n, number of documents containing term
        509 N, total number of documents with field
      0.5635748 tf, computed as freq / (freq + k1 * (1 - b + b * dl / avgdl)) from:
        1.0 freq, occurrences of term within document
        1.2 k1, term saturation parameter
        0.75 b, length normalization parameter
        3.0 dl, length of field
        5.691552 avgdl, average length of field

After adding 500 documents without 🍏, BM25 recalculates IDF for 🍏 with a much larger N, making it appear far rarer in the corpus, so its score contribution more than triples.

Notice that when I queried for 🍎🍏, no documents contained both terms, so the scoring explanation included only one weight. If I modify the query to include 🍎🍏🍊, the document 🍏 🍌 🍊 scores highest, as it combines the weights for both matching terms, 🍏 and 🍊:

4.3254924 sum of:
  3.2850468 weight($type:string/description:🍏 in 205) [BM25Similarity], result of:
    3.2850468 score(freq=1.0), computed as boost * idf * tf from:
      5.8289456 idf, computed as log(1 + (N - n + 0.5) / (n + 0.5)) from:
        1 n, number of documents containing term
        509 N, total number of documents with field
      0.5635748 tf, computed as freq / (freq + k1 * (1 - b + b * dl / avgdl)) from:
        1.0 freq, occurrences of term within document
        1.2 k1, term saturation parameter
        0.75 b, length normalization parameter
        3.0 dl, length of field
        5.691552 avgdl, average length of field
  1.0404456 weight($type:string/description:🍊 in 205) [BM25Similarity], result of:
    1.0404456 score(freq=1.0), computed as boost * idf * tf from:
      1.8461535 idf, computed as log(1 + (N - n + 0.5) / (n + 0.5)) from:
        80 n, number of documents containing term
        509 N, total number of documents with field
      0.5635748 tf, computed as freq / (freq + k1 * (1 - b + b * dl / avgdl)) from:
        1.0 freq, occurrences of term within document
        1.2 k1, term saturation parameter
        0.75 b, length normalization parameter
        3.0 dl, length of field
        5.691552 avgdl, average length of field

Here is the same query in MongoDB:

db.articles.aggregate([
  { $search: { text: { query: ["🍏", "🍊"], path: "description" }, index: "default" } },
  { $project: { _id: 0, score: { $meta: "searchScore" }, description: 1 } },
  { $sort: { score: -1 } },
  { $limit: 15  }
]).forEach( i=> print(i.score.toFixed(3).padStart(5, " "),i.description) )

4.325 🍏 🍌 🍊
1.354 🍎 🍌 🍊 🍊 🍊
1.259 🫐 🍊 🥑 🍊
1.137 🥥 🍊 🍊 🍅 🍈 🍈
1.137 🍍 🍓 🍊 🍊 🥑 🍉
1.137 🥥 🍆 🍊 🍊 🍍 🍉
1.084 🍊 🍑 🍊 🥥 🍌 🍍 🫐
1.084 🍊 🫐 🥝 🍋 🥑 🍇 🍊
1.084 🥭 🍍 🥑 🍋 🍈 🍊 🍊
1.040 🍊 🫐 🥭
1.040 🍊 🍉 🍍
1.040 🍎 🍌 🍊
1.040 🍊 🍋 🍋
1.040 🍐 🍌 🍊
1.036 🍐 🥥 🍍 🍈 🍐 🍊 🍆 🍊

While the scores may feel intuitively correct when you look at the data, it's important to remember there's no magic—everything is based on well‑known mathematics and formulas. Lucene’s scoring algorithms are used in many systems, including Elasticsearch, Apache Solr, and the search indexes built into MongoDB.

Conclusion

MongoDB search indexes are designed to work optimally out of the box. In my earlier post, I relied entirely on default settings, dynamic mapping, and even replaced words with emojis—yet still got relevant, well-ranked results without extra tuning. If you want to go deeper and fine-tune your search behavior, or simply learn more about how it works, inspecting the underlying Lucene index can provide great insights. Since MongoDB Atlas Search indexes are Lucene-compatible, tools like Luke allow you to see exactly how your text is tokenized, stored, and scored—giving you full transparency into how queries match your documents.

MongoDB Search Indexes provide full‑text search capabilities directly within MongoDB, allowing complex queries to be run without copying data to a separate search system. Initially deployed in Atlas, MongoDB’s managed service, Search Indexes are now also part of the community edition. This post compares the default full‑text search behaviour between MongoDB and PostgreSQL, using a simple example to illustrate the ranking algorithm.

Setup: a small dataset

I’ve inserted nine small documents, each consisting of different fruits, using emojis to make it more visual. The 🍎 and 🍏 emojis represent our primary search terms. They appear at varying frequencies in documents of different lengths.

db.articles.deleteMany({});

db.articles.insertMany([
 { description : "🍏 🍌 🍊" },                // short, 1 🍏
 { description : "🍎 🍌 🍊" },                // short, 1 🍎
 { description : "🍎 🍌 🍊 🍎" },             // larger, 2 🍎
 { description : "🍎 🍌 🍊 🍊 🍊" },          // larger, 1 🍎
 { description : "🍎 🍌 🍊 🌴 🫐 🍈 🍇 🌰" },  // large, 1 🍎
 { description : "🍎 🍎 🍎 🍎 🍎 🍎" },       // large, 6 🍎
 { description : "🍎 🍌" },                 // very short, 1 🍎
 { description : "🍌 🍊 🌴 🫐 🍈 🍇 🌰 🍎" },  // large, 1 🍎
 { description : "🍎 🍎 🍌 🍌 🍌" },          // shorter, 2 🍎
]);

To enable dynamic indexing, I created a MongoDB Search Index without specifying any particular field names:

db.articles.createSearchIndex("default",
  { mappings: { dynamic: true } }
);

I created the equivalent on PostgreSQL:

DROP TABLE IF EXISTS articles;
CREATE TABLE articles (
    id BIGSERIAL PRIMARY KEY,
    description TEXT
);

INSERT INTO articles(description) VALUES
('🍏 🍌 🍊'),
('🍎 🍌 🍊'),
('🍎 🍌 🍊 🍎'),
('🍎 🍌 🍊 🍊 🍊'),
('🍎 🍌 🍊 🌴 🫐 🍈 🍇 🌰'),
('🍎 🍎 🍎 🍎 🍎 🍎'),
('🍎 🍌'),
('🍌 🍊 🌴 🫐 🍈 🍇 🌰 🍎'),
('🍎 🍎 🍌 🍌 🍌');

Since text search needs multiple index entries for each row, I set up a GIN (Generalized Inverted Index) and use tsvector to extract and index the relevant tokens.

CREATE INDEX articles_fts_idx
  ON articles USING GIN (to_tsvector('simple', description))
;

MongoDB Text Search (Lucene BM25):

I use my custom search index to find articles containing either 🍎 or 🍏 in their descriptions. The results are sorted by relevance score and displayed as follows:

db.articles.aggregate([
  { $search: { text: { query: ["🍎", "🍏"], path: "description" }, index: "default" } },
  { $project: { _id: 0, score: { $meta: "searchScore" }, description: 1 } },
  { $sort: { score: -1 } }
]).forEach( i=> print(i.score.toFixed(3).padStart(5, " "),i.description) )

Here are the results, presented in order of best to worst match:

1.024 🍏 🍌 🍊
0.132 🍎 🍎 🍎 🍎 🍎 🍎
0.107 🍎 🍌 🍊 🍎
0.101 🍎 🍎 🍌 🍌 🍌
0.097 🍎 🍌
0.088 🍎 🍌 🍊
0.073 🍎 🍌 🍊 🍊 🍊
0.059 🍎 🍌 🍊 🌴 🫐 🍈 🍇 🌰
0.059 🍌 🍊 🌴 🫐 🍈 🍇 🌰 🍎

All documents were retrieved by this search since each contains a red or green apple. However, they are assigned different scores:

• Multiple appearances boost the score: When a document contains the search term more than once, its ranking increases compared to those with only a single appearance. That's why documents featuring several 🍎 are ranked higher than those containing only one.
• Rarity outweighs quantity: When a term like 🍎 appears in every document, it has less impact than a rare term, such as 🍏. Therefore, even if 🍏 only appears once, the document containing it ranks higher than others with multiple 🍎. In this model, rarity carries more weight than mere frequency.
• Diminishing returns on term frequency: Each extra occurrence of a term adds less to the relevance score. For instance, increasing 🍎 from one to six times (from 🍎 🍌 to 🍎 🍎 🍎 🍎 🍎 🍎) boosts the score, but not by a factor of six. The effect of term repetition diminishes as the count rises.
• Document length matters: A term that appears only once is scored higher in a short document than in a long one. That's why 🍎 🍌 ranks higher than 🍎 🍌 🍊, which itself ranks higher than 🍎 🍌 🍊 🍊 🍊.

MongoDB Atlas Search indexes are powered by Lucene’s BM25 algorithm, a refinement of the classic TF‑IDF model:

• Term Frequency (TF): More occurrences of a term in a document increase its relevance score, but with diminishing returns.
• Inverse Document Frequency (IDF): Terms that appear in fewer documents receive higher weighting.
• Length Normalization: Matches in shorter documents contribute more to relevance than the same matches in longer documents.

To demonstrate the impact of IDF, I added several documents that do not contain any of the apples I'm searching for.

const fruits = [ "🍐","🍊","🍋","🍌","🍉","🍇","🍓","🫐",         
                 "🥝","🥭","🍍","🥥","🍈","🍅","🥑","🍆",  
                 "🍋","🍐","🍓","🍇","🍈","🥭","🍍","🍑",  
                 "🥝","🫐","🍌","🍉","🥥","🥑","🥥","🍍" ];
function randomFruitSentence(min=3, max=8) {
  const len = Math.floor(Math.random() * (max - min + 1)) + min;
  return Array.from({length: len}, () => fruits[Math.floor(Math.random()*fruits.length)]).join(" ");
}
db.articles.insertMany(
  Array.from({length: 500}, () => ({ description: randomFruitSentence() }))
);

db.articles.aggregate([
  { $search: { text: { query: ["🍎", "🍏"], path: "description" }, index: "default" } },
  { $project: { _id: 0, score: { $meta: "searchScore" }, description: 1 } },
  { $sort: { score: -1 } }
]).forEach( i=> print(i.score.toFixed(3).padStart(5, " "),i.description) )

3.365 🍎 🍎 🍎 🍎 🍎 🍎
3.238 🍏 🍌 🍊
2.760 🍎 🍌 🍊 🍎
2.613 🍎 🍎 🍌 🍌 🍌
2.506 🍎 🍌
2.274 🍎 🍌 🍊
1.919 🍎 🍌 🍊 🍊 🍊
1.554 🍎 🍌 🍊 🌴 🫐 🍈 🍇 🌰
1.554 🍌 🍊 🌴 🫐 🍈 🍇 🌰 🍎

Although the result set is unchanged, the score has increased and the frequency gap between 🍎 and 🍏 has narrowed. As a result, 🍎 🍎 🍎 🍎 🍎 🍎 now ranks higher than 🍏 🍌 🍊, since the inverse document frequency (IDF) of 🍏 does not fully offset its term frequency (TF) within a single document. Crucially, changes made in other documents can influence the score of any given document, unlike in traditional indexes where changes in one document do not impact others' index entries.

PostgreSQL Text Search (TF only):

Here is the result in PostgreSQL:

SELECT ts_rank_cd(  

        to_tsvector('simple', description)
     ,  
        to_tsquery('simple', '🍎 | 🍏')  

       ) AS score, description  
FROM articles  
WHERE
       to_tsvector('simple', description) 
    @@ 
       to_tsquery('simple', '🍎 | 🍏')  

ORDER BY score DESC;  

It retrieves the same documents, but with many having the same score, even with different patterns:

 score |       description
-------+-------------------------
   0.6 | 🍎 🍎 🍎 🍎 🍎 🍎
   0.2 | 🍎 🍌 🍊 🍎
   0.2 | 🍎 🍎 🍌 🍌 🍌
   0.1 | 🍏 🍌 🍊
   0.1 | 🍎 🍌
   0.1 | 🍌 🍊 🌴 🫐 🍈 🍇 🌰 🍎
   0.1 | 🍎 🍌 🍊 🌴 🫐 🍈 🍇 🌰
   0.1 | 🍎 🍌 🍊
   0.1 | 🍎 🍌 🍊 🍊 🍊
(9 rows)

With PostgreSQL text search, only the term frequency (TF) matters, and is a direct multiplicator of the score: 6 apples ranks 3x higher than two, and 6x than one.

There's some possible normalization available with additiona flags:

SELECT ts_rank_cd(
         to_tsvector('simple', description),
         to_tsquery('simple', '🍎 | 🍏')  ,
            0 -- (the default) ignores the document length
         |  1 -- divides the rank by 1 + the logarithm of the document length
    --   |  2 -- divides the rank by the document length
    --   |  4 -- divides the rank by the mean harmonic distance between extents (this is implemented only by ts_rank_cd)
         |  8 -- divides the rank by the number of unique words in document
    --   | 16 -- divides the rank by 1 + the logarithm of the number of unique words in document
    --   | 32 -- divides the rank by itself + 1
       ) AS score,
       description
FROM articles
WHERE to_tsvector('simple', description) @@ to_tsquery('simple', '🍎 | 🍏')
ORDER BY score DESC
;
    score    |       description
-------------+-------------------------
    0.308339 | 🍎 🍎 🍎 🍎 🍎 🍎
 0.055811062 | 🍎 🍎 🍌 🍌 🍌
  0.04551196 | 🍎 🍌
  0.04142233 | 🍎 🍌 🍊 🍎
 0.024044918 | 🍏 🍌 🍊
 0.024044918 | 🍎 🍌 🍊
 0.018603688 | 🍎 🍌 🍊 🍊 🍊
 0.005688995 | 🍎 🍌 🍊 🌴 🫐 🍈 🍇 🌰
 0.005688995 | 🍌 🍊 🌴 🫐 🍈 🍇 🌰 🍎
(9 rows)

This penalizes longer documents and those with more unique terms. Still, it doesn't consider other documents like IDF.

PostgreSQL Full Text Search scoring with ts_rank_cd is based on term frequency and proximity. It does not compute inverse document frequency, so scores do not change as the corpus changes. Normalization flags can penalize long documents or those with many unique terms, but they are length-based adjustments, not true IDF, like we have in TF‑IDF or BM25‑style search engine.

ParadeDB with pg_search (Tantivy BM25)

PostgreSQL popularity is not only due to its features but also its extensibility and ecosystem. The pg_search extension adds functions and operators that use BM25 indexes (Tantivy, a Rust-based search library inspired by Lucene). It is easy to test with ParadeDB:

docker run --rm -it paradedb/paradedb bash

POSTGRES_PASSWORD=x docker-entrypoint.sh postgres &

psql -U postgres

The extension is installed in version 0.18.4:

postgres=# \dx
                                        List of installed extensions
          Name          | Version |   Schema   |                        Description
------------------------+---------+------------+------------------------------------------------------------
 fuzzystrmatch          | 1.2     | public     | determine similarities and distance between strings
 pg_cron                | 1.6     | pg_catalog | Job scheduler for PostgreSQL
 pg_ivm                 | 1.9     | pg_catalog | incremental view maintenance on PostgreSQL
 pg_search              | 0.18.4  | paradedb   | pg_search: Full text search for PostgreSQL using BM25
 plpgsql                | 1.0     | pg_catalog | PL/pgSQL procedural language
 postgis                | 3.6.0   | public     | PostGIS geometry and geography spatial types and functions
 postgis_tiger_geocoder | 3.6.0   | tiger      | PostGIS tiger geocoder and reverse geocoder
 postgis_topology       | 3.6.0   | topology   | PostGIS topology spatial types and functions
 vector                 | 0.8.0   | public     | vector data type and ivfflat and hnsw access methods
(9 rows)

I created and inserted the same as I did above on PostgreSQL and created the BM25 index:

CREATE INDEX search_idx ON articles
       USING bm25 (id, description)
       WITH (key_field='id')
;

We can query using the @@@ operator and rank with paradedb.score(id). Unlike PostgreSQL’s built‑in @@, which uses query‑local statistics, @@@ computes scores using global IDF and Lucene’s BM25 length normalization — so adding unrelated documents can still change the scores.

SELECT description, paradedb.score(id) AS score
FROM articles
WHERE description @@@ '🍎' OR description @@@ '🍏'
ORDER BY score DESC, description;

 description | score
-------------+-------
(0 rows)

The result is empty. Using emoji as terms can lead to inconsistent tokenization results, so I replaced them with text labels instead:

UPDATE articles SET description 
 = replace(description, '🍎', 'Gala');
UPDATE articles SET description 
 = replace(description, '🍏', 'Granny Smith');
UPDATE articles SET description 
 = replace(description, '🍊', 'Orange');

This time, the scoring is more precise and takes into account the term frequency within the document (TF), the term’s rarity across the entire indexed corpus (IDF), along with a length normalization factor to prevent longer documents from having an unfair advantage:

SELECT description, paradedb.score(id) AS score
FROM articles
WHERE description @@@ 'Gala' OR description @@@ 'Granny Smith'
ORDER BY score DESC, description;

          description          |   score
-------------------------------+------------
 Granny Smith 🍌 Orange        |  3.1043208
 Gala Gala Gala Gala Gala Gala | 0.79529095
 Gala Gala 🍌 🍌 🍌            |  0.7512194
 Gala 🍌                       | 0.69356775
 Gala 🍌 Orange Gala           | 0.63589364
 Gala 🍌 Orange                |  0.5195716
 Gala 🍌 Orange 🌴 🫐 🍈 🍇   |  0.5195716
 🍌 Orange 🌴 🫐 🍈 🍇   Gala |  0.5195716
 Gala 🍌 Orange Orange Orange  | 0.34597924
(9 rows)

PostgreSQL’s built-in search only provides basic, local term frequency scoring. To get a full-feature text search that can be used in application's search boxes, it can be extended with third-party tools like ParadeDB's pg_search.

Conclusion

Relevance scoring in text search can differ widely between systems because each uses its own ranking algorithms and analyzers. To better visualize my results in these tests, I used emojis and opted for the simplest definitions. I selected PostgreSQL's to_tsvector('simple') configuration to prevent language-specific processing, while for MongoDB Atlas Search, I used the default dynamic mapping.

MongoDB Atlas Search (and now in MongoDB Community Edition) uses Lucene’s BM25 algorithm, combining:

• Term Frequency (TF): Frequent terms in a document boost scores, but with diminishing returns
• Inverse Document Frequency (IDF): Rare terms across the corpus get higher weight
• Length normalization: Matches in shorter documents are weighted more than the same matches in longer ones

PostgreSQL’s full-text search (ts_rank_cd()) evaluates only term frequency and position, overlooking other metrics like IDF. For more advanced features such as BM25, extensions like ParadeDB’s pg_search are needed, which require extra configuration and are not always available on managed platforms. PostgreSQL offers a modular approach, where extensions can add advanced ranking algorithms like BM25. MongoDB provides built‑in BM25‑based full‑text search in both Atlas and the Community Edition.

MongoDB search indexes provide full‑text search capabilities directly within MongoDB, allowing complex queries to be run without copying data to a separate search system. Initially deployed in Atlas, MongoDB’s managed service, search indexes are now also part of the community edition. This post compares the default full‑text search behaviour between MongoDB and PostgreSQL, using a simple example to illustrate the ranking algorithm.

Setup: a small dataset

I’ve inserted nine small documents, each consisting of different fruits, using emojis to make it more visual. The 🍎 and 🍏 emojis represent our primary search terms. They appear at varying frequencies in documents of different lengths.

db.articles.deleteMany({});

db.articles.insertMany([
 { description : "🍏 🍌 🍊" },                // short, 1 🍏
 { description : "🍎 🍌 🍊" },                // short, 1 🍎
 { description : "🍎 🍌 🍊 🍎" },             // larger, 2 🍎
 { description : "🍎 🍌 🍊 🍊 🍊" },          // larger, 1 🍎
 { description : "🍎 🍌 🍊 🌴 🫐 🍈 🍇 🌰" },  // large, 1 🍎
 { description : "🍎 🍎 🍎 🍎 🍎 🍎" },       // large, 6 🍎
 { description : "🍎 🍌" },                 // very short, 1 🍎
 { description : "🍌 🍊 🌴 🫐 🍈 🍇 🌰 🍎" },  // large, 1 🍎
 { description : "🍎 🍎 🍌 🍌 🍌" },          // shorter, 2 🍎
]);

To enable dynamic indexing, I created a MongoDB search index without specifying any particular field names:

db.articles.createSearchIndex("default",
  { mappings: { dynamic: true } }
);

I created the equivalent on PostgreSQL:

DROP TABLE IF EXISTS articles;
CREATE TABLE articles (
    id BIGSERIAL PRIMARY KEY,
    description TEXT
);

INSERT INTO articles(description) VALUES
('🍏 🍌 🍊'),
('🍎 🍌 🍊'),
('🍎 🍌 🍊 🍎'),
('🍎 🍌 🍊 🍊 🍊'),
('🍎 🍌 🍊 🌴 🫐 🍈 🍇 🌰'),
('🍎 🍎 🍎 🍎 🍎 🍎'),
('🍎 🍌'),
('🍌 🍊 🌴 🫐 🍈 🍇 🌰 🍎'),
('🍎 🍎 🍌 🍌 🍌');

Since text search needs multiple index entries for each row, I set up a Generalized Inverted Index (GIN) and use tsvector to extract and index the relevant tokens.

CREATE INDEX articles_fts_idx
  ON articles USING GIN (to_tsvector('simple', description))
;

MongoDB text search (Lucene BM25):

I use my custom search index to find articles containing either 🍎 or 🍏 in their descriptions. The results are sorted by relevance score and displayed as follows:

db.articles.aggregate([
  { $search: { text: { query: ["🍎", "🍏"], path: "description" }, index: "default" } },
  { $project: { _id: 0, score: { $meta: "searchScore" }, description: 1 } },
  { $sort: { score: -1 } }
]).forEach( i=> print(i.score.toFixed(3).padStart(5, " "),i.description) )

Here are the results, presented in order of best to worst match:

1.024 🍏 🍌 🍊
0.132 🍎 🍎 🍎 🍎 🍎 🍎
0.107 🍎 🍌 🍊 🍎
0.101 🍎 🍎 🍌 🍌 🍌
0.097 🍎 🍌
0.088 🍎 🍌 🍊
0.073 🍎 🍌 🍊 🍊 🍊
0.059 🍎 🍌 🍊 🌴 🫐 🍈 🍇 🌰
0.059 🍌 🍊 🌴 🫐 🍈 🍇 🌰 🍎

All documents were retrieved by this search since each contains a red or green apple. However, they are assigned different scores:

• Multiple appearances boost the score: When a document contains the search term more than once, its ranking increases compared to those with only a single appearance. That's why documents featuring several 🍎 are ranked higher than those containing only one.
• Rarity outweighs quantity: When a term like 🍎 appears in every document, it has less impact than a rare term, such as 🍏. Therefore, even if 🍏 only appears once, the document containing it ranks higher than others with multiple 🍎. In this model, rarity carries more weight than mere frequency.
• Diminishing returns on term frequency: Each extra occurrence of a term adds less to the relevance score. For instance, increasing 🍎 from one to six times (from 🍎 🍌 to 🍎 🍎 🍎 🍎 🍎 🍎) boosts the score, but not by a factor of six. The effect of term repetition diminishes as the count rises.
• Document length matters: A term that appears only once is scored higher in a short document than in a long one. That's why 🍎 🍌 ranks higher than 🍎 🍌 🍊, which itself ranks higher than 🍎 🍌 🍊 🍊 🍊.

MongoDB Atlas Search indexes are powered by Lucene’s BM25 algorithm, a refinement of the classic TF‑IDF model:

• Term frequency (TF): More occurrences of a term in a document increase its relevance score, but with diminishing returns.
• Inverse document frequency (IDF): Terms that appear in fewer documents receive higher weighting.
• Length normalization: Matches in shorter documents contribute more to relevance than the same matches in longer documents.

To demonstrate the impact of IDF, I added several documents that do not contain any of the apples I'm searching for.

const fruits = [ "🍐","🍊","🍋","🍌","🍉","🍇","🍓","🫐",         
                 "🥝","🥭","🍍","🥥","🍈","🍅","🥑","🍆",  
                 "🍋","🍐","🍓","🍇","🍈","🥭","🍍","🍑",  
                 "🥝","🫐","🍌","🍉","🥥","🥑","🥥","🍍" ];
function randomFruitSentence(min=3, max=8) {
  const len = Math.floor(Math.random() * (max - min + 1)) + min;
  return Array.from({length: len}, () => fruits[Math.floor(Math.random()*fruits.length)]).join(" ");
}
db.articles.insertMany(
  Array.from({length: 500}, () => ({ description: randomFruitSentence() }))
);

db.articles.aggregate([
  { $search: { text: { query: ["🍎", "🍏"], path: "description" }, index: "default" } },
  { $project: { _id: 0, score: { $meta: "searchScore" }, description: 1 } },
  { $sort: { score: -1 } }
]).forEach( i=> print(i.score.toFixed(3).padStart(5, " "),i.description) )

3.365 🍎 🍎 🍎 🍎 🍎 🍎
3.238 🍏 🍌 🍊
2.760 🍎 🍌 🍊 🍎
2.613 🍎 🍎 🍌 🍌 🍌
2.506 🍎 🍌
2.274 🍎 🍌 🍊
1.919 🍎 🍌 🍊 🍊 🍊
1.554 🍎 🍌 🍊 🌴 🫐 🍈 🍇 🌰
1.554 🍌 🍊 🌴 🫐 🍈 🍇 🌰 🍎

Although the result set is unchanged, the score has increased and the frequency gap between 🍎 and 🍏 has narrowed. As a result, 🍎 🍎 🍎 🍎 🍎 🍎 now ranks higher than 🍏 🍌 🍊, since the inverse document frequency (IDF) of 🍏 does not fully offset its term frequency (TF) within a single document. Crucially, changes made in other documents can influence the score of any given document, unlike in traditional indexes, where changes in one document do not impact others' index entries.

PostgreSQL text search (TF only):

Here is the result in PostgreSQL:

SELECT ts_rank_cd(  

        to_tsvector('simple', description)
     ,  
        to_tsquery('simple', '🍎 | 🍏')  

       ) AS score, description  
FROM articles  
WHERE
       to_tsvector('simple', description) 
    @@ 
       to_tsquery('simple', '🍎 | 🍏')  

ORDER BY score DESC;  

It retrieves the same documents, but with many having the same score, even with different patterns:

 score |       description
-------+-------------------------
   0.6 | 🍎 🍎 🍎 🍎 🍎 🍎
   0.2 | 🍎 🍌 🍊 🍎
   0.2 | 🍎 🍎 🍌 🍌 🍌
   0.1 | 🍏 🍌 🍊
   0.1 | 🍎 🍌
   0.1 | 🍌 🍊 🌴 🫐 🍈 🍇 🌰 🍎
   0.1 | 🍎 🍌 🍊 🌴 🫐 🍈 🍇 🌰
   0.1 | 🍎 🍌 🍊
   0.1 | 🍎 🍌 🍊 🍊 🍊
(9 rows)

With PostgreSQL text search, only the term frequency (TF) matters, and is a direct multiplicator of the score: six apples rank three times higher than two, and six times higher than one.

There's some possible normalization available with additiona flags:

SELECT ts_rank_cd(
         to_tsvector('simple', description),
         to_tsquery('simple', '🍎 | 🍏')  ,
            0 -- (the default) ignores the document length
         |  1 -- divides the rank by 1 + the logarithm of the document length
    --   |  2 -- divides the rank by the document length
    --   |  4 -- divides the rank by the mean harmonic distance between extents (this is implemented only by ts_rank_cd)
         |  8 -- divides the rank by the number of unique words in document
    --   | 16 -- divides the rank by 1 + the logarithm of the number of unique words in document
    --   | 32 -- divides the rank by itself + 1
       ) AS score,
       description
FROM articles
WHERE to_tsvector('simple', description) @@ to_tsquery('simple', '🍎 | 🍏')
ORDER BY score DESC
;
    score    |       description
-------------+-------------------------
    0.308339 | 🍎 🍎 🍎 🍎 🍎 🍎
 0.055811062 | 🍎 🍎 🍌 🍌 🍌
  0.04551196 | 🍎 🍌
  0.04142233 | 🍎 🍌 🍊 🍎
 0.024044918 | 🍏 🍌 🍊
 0.024044918 | 🍎 🍌 🍊
 0.018603688 | 🍎 🍌 🍊 🍊 🍊
 0.005688995 | 🍎 🍌 🍊 🌴 🫐 🍈 🍇 🌰
 0.005688995 | 🍌 🍊 🌴 🫐 🍈 🍇 🌰 🍎
(9 rows)