https://typesense.org logo
Join Slack
Powered by
# community-help
  • g
    Prefix filtering in filter_by on a string[] field seems capped at 4 distinct values — expected? Typesense v31.0.rc12 I filter products by category path. Each product has a string[] of hierarchical paths: "categories[].categories_id.slugPath": ["alimentation/miel", "alimentation/miel/miel-de-foret"] Field schema: {"name":"categories[].categories_id.slugPath","type":"string[]","facet":true,"infix":true,"optional":true} To get "this category + all its descendants" I use a prefix filter: categories[].categories_id.slugPath:[
    alimentation
    , 
    alimentation/*
    ] → found: 60 The equivalent exact filter on our denormalized label field returns 167: categories.fr-CH.lvl0:=
    Alimentation
    → found: 167 Faceting the truncated result shows exactly what happened — only 4 paths actually drove the match: 24 alimentation/autres-produits/superaliments 16 alimentation/autres-produits/condiments/miso 13 alimentation/fruits-baies-et-noix/produits-de-fruits/fruits-secs 7 alimentation/miel --- 60 = found Things that do not help: • max_candidates (tried up to 10000) — seems to apply only to q, not filter_by • exhaustive_search=true Questions 1. Is this 4-value cap on prefix expansion in filter_by intended / documented? 2. Is there a way to raise it for filter_by (a max_candidates equivalent)? 3. If not, what's the recommended way to filter "category + descendants" over a string[] of paths? Enumerating every descendant value in :[...] works, but requires a separate facet query first. Thanks!
    j
    • 2
    • 2
  • a
    How can i sort search results by specific collections? Like i want to show matches 
    brands
    collection first and then others
    f
    • 2
    • 3
  • r
    Hello, Our Typesense node is running at nearly 100% CPU utilization almost continuously, and the node frequently becomes unhealthy. Background After performing a full site indexing, the CPU remained at 100% for an extended period, causing search requests to fail. After discussing the issue here previously, we upgraded the instance from 2 vCPUs to 4 vCPUs. Current environment • Typesense v30.2 • Single-node cluster (Frankfurt) • 4 vCPUs • 16 GB RAM • Regular SSD • Automatic Capacity Upgrade: Disabled Our data is distributed across two collections: • ~500,000 documents • ~100,000 documents We expected this dataset and traffic volume to be well within the capacity of the node. Search traffic is only around 5–7 requests per second, yet the CPU remains close to 100% most of the time and the node frequently becomes unhealthy. Has anyone experienced something similar, or are there any recommendations on what we should investigate next? Thanks! @Kishore Nallan @Jason Bosco
    a
    • 2
    • 3
  • m
    Can someone clarify these docs regarding un-indexed fields? > “You want to NOT mention these fields in the collection's schema or mark these fields as `index: false`…” I am confused on the wording. It can be understood as: Do not mention the fields in the schema, and also do not mark them as 
    index: false
    .     But I think the intended meaning is: Either do not mention the fields in the schema, or add them to the schema with 
    index: false
    .     In other words, are both of these valid ways to make a field unindexed and stored only on disk?
    f
    • 2
    • 1
  • r
    Hi everyone, I'm pretty new to the Typesense community and have been experimenting with building Typesense from source for both AMD64 and ARM64 targets. So far, I've had great success with AMD64. I'm building with Bazel, and the resulting image passes tests and appears to work as expected. Where I'm getting stuck is ARM64. When I build from source and run the ARM64 image, write requests hang indefinitely on the first write operation. I've been able to reproduce this on both Apple Silicon and Linux ARM environments. What's interesting is that the official 
    typesense/typesense
    The ARM64 image from Docker Hub works perfectly on the same machines, suggesting I may be missing something in my build process rather than a general ARM issue. Before I go too far down the rabbit hole, I was curious if anyone could point me toward how the official ARM64 images are produced. Are they built directly from the public repo with Bazel, or is there a different toolchain, configuration, compiler version, build flags, or CI pipeline involved? I'm mainly trying to learn the supported build path for both AMD64 and ARM64, and would appreciate any guidance from folks who have worked with the build system. Thanks in advance!
    j
    • 2
    • 4
  • p
    Has anyone migrated from private RTD-hosted doc site search to Typesense? I would like to hear from you.
    a
    • 2
    • 2
  • k
    Hey all, Just wanted to let you know that Sequin (which docs recommend) is probably unmaintained. Not officially, but given lack of response from maintainers over past months and lack of commits in Sequin's repo, the Typesense docs recommending it feel stale. Don't get me wrong, it works, but a warning / note in the docs could be noteworthy. typesense.org/docs/guide/syncing-data-into-typesense.html#…
    a
    • 2
    • 3
  • l
    Hey, i'm hitting a performance wall on the same-object array filter (
    parent.{a && b}
    ) and hoping someone can tell me whether it's usable at all. I'm testing with 50k docs, 
    items
    is an 
    object[]
    of 
    {code, value}
    , 
    items.code
    is 
    string[]
    faceted, 
    items.value
    is 
    int32[]
    with 
    range_index
    . On 31.0.rc12: • 
    items.{code:=DE && value:>=20}
    → 1400ms (9,693 matches) • 
    items.code:=DE
    alone → 6ms • 
    items.value:>=20
    alone → 11ms (47,540 matches) Each condition is fine on its own, only the same-element form is scaling terribly: 4.5s once documents are ~15kb, and 6s for a code that appears in half the collection. I also commented on github.com/typesense/typesense/issues/2469#… with a reproduction script. Is there a way to make this work at this size, or is a fix planned? It's the only way to express "one array element matches both conditions".
    a
    • 2
    • 4
  • a
    @Fanis Tharropoulos @Alan Martini @Kishore Nallan We are facing an issue with Typesense filtering where adding an additional 
    bookType
    value results in fewer search results. For the search query `"sudha murthy"`: Filter 1:
    Copy code
    isOutOfStock:N && bookType:[0,3,2]
    Returns 12 results. Filter 2:
    Copy code
    isOutOfStock:N && bookType:[0,3]
    Returns 18 results. Since 
    [0,2]
    is a subset of 
    [0,3,2]
    , we expected the first query to return at least the same number of results as the second query. Could you please help us understand why the broader filter is returning fewer results?
    Copy code
    curl --location '<https://ew5h2tr67livkp41p-1.a1.typesense.net/multi_search?use_cache=true&x-typesense-api-key=ynYXfz3KuyLdSvLrMitLZWtsOImkATlb>' \
--header 'Content-Type: application/json' \
--data '{
    "searches": [
        {
            "q": "sudha murthy",
            "query_by": "isbn,title,author,publication,category,subject,categories.lvl0,categories.lvl1,categories.lvl2,categories.lvl3,categories.lvl4",
            "prioritize_token_position": true,
            "max_facet_values": 50,
            "num_typos": 2,
            "min_len_1typo": 2,
            "split_join_tokens": "always",
            "typo_tokens_threshold": 10,
            "per_page": 32,
            "filter_by": "isOutOfStock:N && bookType:[0,3,2]",
            "sort_by": "num_is_out_of_stack:asc,ranking:desc,_text_match:desc",
            "pre_segmented_query": true,
            "drop_tokens_threshold": 10,
            "facet_sample_threshold": 1000,
            "facet_sample_percent": 20,
            "use_cache": true,
            "exclude_fields": "embedding",
            "highlight_full_fields": "isbn,title,author,publication,category,subject,categories.lvl0,categories.lvl1,categories.lvl2,categories.lvl3,categories.lvl4",
            "collection": "books_collection",
            "facet_by": "agedGroup,author,binding,bookCondition,categories.lvl0,isOutOfStock,language,price,publication",
            "page": 1
        }
    ]
}'
    f
    • 2
    • 1
  • n
    Is it possible that if you have HA enabled, then all servers are not in sync with each other for hours? I had a strange issue on Friday where I was able to query for some data from the same cluster but not my client and they tried everything! I had to sync the data once more for multiple collections (had already synced once for the main one earlier), and then it started working. This caused a lot of confusion for my client's customers
    a
    • 2
    • 1
  • r
    Hi ..We're running Typesense 30.1 self-hosted and seeing inconsistent behavior with curation sets. We use 
    filter_by
    together with 
    remove_matched_tokens: true
    . Some rules work correctly, while other rules with the same configuration shape don't appear to fire. Working examples: • 
    script
    , 
    display
    , 
    slab
    , 
    grotesk
    • 
    sonakshi
    → 
    is_var:=true
    → 406 expected results Not working: • 
    blackletter
    → 
    font_cat_en:="blackletter"
    → expected ~358, getting ~18 normal name matches • 
    scary
    → 
    tags_font_en:="horror"
    → expected ~126, getting normal name matches • 
    variable
    → 
    is_var:=true
    → expected 406, getting ~332 name matches We also tested 
    replace_query
    instead of 
    remove_matched_tokens
    , with the same behavior. Is there anything in tokenization/query processing that could cause certain query strings not to trigger an otherwise identical curation rule?
    h
    a
    +2
    • 5
    • 18
  • d
    Hi! We are facing an issue with a configuration update on our cluster. It's been running for more than 2hours+ now and no idea why. Can someone please help take a look? Cluster: nsuzl168vgwda53qp
    a
    • 2
    • 2
  • s
    Hi, we are running Typesense 30.1 and have set the 
    max_per_page
    value to 1000, but we are still getting an error saying that only up to 250 hits can be fetched per page. Can anyone help with this? Error: 
    Request failed with HTTP code 422 | Server said: Only up to 250 hits can be fetched per page.
    a
    • 2
    • 4
  • h
    Hey everyone 👋 Two things we could use help with. We have a float[] vector field (768-dim, HNSW) on a 3-node cluster (~8GB RAM) that intermittently goes missing from documents after a bulk upsert — payload has it, response says success: true, but a query right after shows the field completely absent. Reproduced something similar locally: Docker with a constrained memory limit + repeated bulk upserts eventually got the container OOM-killed. Wondering if brief memory spikes during large batches could cause a silent partial write (raft commit succeeds, index apply fails) without erroring back to the client. Anyone seen this, or know how to get finer-grained memory visibility to correlate with specific writes? Also — we're building semantic/vector search on top of Typesense and weighing native hybrid search (vector + keyword on the same collection) vs. a separate vector collection. Any guidance on which is better at scale, or on handling embedding refresh cleanly? Happy to share exact payloads if useful.
    a
    • 2
    • 6
  • k
    Hello! We recently had to use 
    .export
    method on JS client and we noticed that in one of our runs (preceeded with a lot of upserts and deletes to the TS collection done through Sequin CDC), exporting the collection + JSON parsing it shortly after crashed our code.
    Copy code
    Typesense export returned a non-JSON line: Error while getting seq_id of `63378`: Not found.
    Copy code
    const exportedDocuments = await client
    .collections(collection)
    .documents()
    .export({ include_fields: TS_INCLUDED_FIELDS });

  const tsDocuments = exportedDocuments
    .split('\n')
    .filter((line) => line.trim().length > 0)
    .map((line) => JSON.parse(line) as { id: string; key: string });
    I think it could be due to the Sequin applying all buffered changes (deletes in this case) while export was ongoing, but a confirmation would nice. Is this the only error one can run into with export API? I find that this feature is a bit underdocumented: typesense.org/docs/30.2/api/documents.html#…
    a
    • 2
    • 6
  • s
    @Jason Bosco Could you check our production search cluster? We have a node stuck with pending writes. We tried a redeploy by initiating a configuration change but not change any settings. And now after 10 minutes into that config change, no nodes have restarted.
    a
    j
    • 3
    • 18
  • j
    Hello, I need help re-syncing some nodes from the leader’s snapshot. 3 nodes HA, 16 GB / 4 vCPU (5 hr burst), v30.2. Nodes 1 and 2 (followers) have been unhealthy and have not recovered. Node 3 (leader) is healthy and serving 100% of traffic alone. Pending write batches are frozen at ~12,000 and ~10,700 for over an hour but Mem and Disk are nowhere near capacity. I tried to do the rolling restart but think it’s stuck because there’s only one healthy node. Is there any way to re-sync nodes 1 and 2 from the leader?
    j
    • 2
    • 9
  • k
    Hi good morning folks, quick question. Do you have already hardened images for typesense? If not, are there any plans for them?
    f
    • 2
    • 4
  • a
    Hello, we have reproduced a timeout in Typesense 30.2 when using a grouped nested filter and one of the fields inside the nested object is an array of strings. Schema
    Copy code
    {
  "name": "repro_nested_string_array",
  "enable_nested_fields": true,
  "fields": [
    {
      "name": "title",
      "type": "string"
    },
    {
      "name": "items",
      "type": "object[]"
    },
    {
      "name": "items.supplierId",
      "type": "string[]",
      "facet": true
    },
    {
      "name": "items.centerList",
      "type": "string[]",
      "facet": true
    }
  ]
}
    Document
    Copy code
    {
  "id": "doc1",
  "title": "M26192-UN",
  "items": [
    {
      "supplierId": "4000012571",
      "centerList": [
        "ES081151"
      ]
    }
  ]
}
    Query
    Copy code
    filter_by=items.{supplierId:=4000012571 && centerList:=ES081151}
    The query does not return a response and times out, even though the collection contains only one document. The issue appears to be specifically related to using a grouped nested filter with an 
    object[]
    field where one of the nested fields is itself a 
    string[]
    . Could you please confirm whether this is a known issue or limitation in Typesense 30.2, and whether it has been fixed in a newer version?
    f
    • 2
    • 3
  • g
    Hello 🙂 We are now client of Typesense cloud for over a year, and while we are very satisfied by the product, the payment process is the worst I have to deal with ATM. • First, TypeSense seems incapable of remembering my payment info, so each time I want to top-up credits, I need to fill the card details. • Secondly, this top-up system is annoying ; why can't we get a monthly payment of the amount we used, like most other pay-as-you-go services? Having to think about topping up is annoying. • Thirdly, why is invoicing per-week? If I am off for two weeks, and we are running out of credits, I need to handle 2 invoices instead of a single one for the current month. • And last, why can't we easily download PDF receipts / invoices? Yes, I can print them, but it's annoying to have to think about it each time I need to handle Typesense' invoicing (which is already too often). Plus, the receipts aren't sent as PDF so I can't forward them to the central payment system either. Overall, the experience really feels cumbersome, and way under what the market usually offers. I really hope its something you can dedicate a bit of engineering time to get to a decent level. 🙂 And please take this as constructive feedback from someone frustrated by an otherwise genuinely good product we are happy of.
    a
    • 2
    • 4
  • l
    Hi! I updated my schema with a new API key for embeddings using this solution. Unfortunately, now my cluster is returning an error saying the field doesn't exist ([Errno 400] Malformed vector query string: could not find a field named 
    description_embedding
    .). This field already existed in the original schema and when I list the existing schema, it is also present. Any idea what could cause this ?
    f
    • 2
    • 11
  • l
    Hi! Using built-in NLS on v29.1. 
    generate_schema_prompt()
    caps facet values at 20 fetched / 10 shown, ordered by frequency, so on a 23-value field the 13 rarest never reach the LLM. The model doesn't abstain when a value is hidden, it filters on the nearest visible one instead, which silently returns a large and wrong result set rather than an error. Listing values in 
    system_prompt
    fixes it, but doesn't scale to hierarchy levels with ~400 values. Is there a runtime way to raise those caps, or is #2954 on the roadmap? My company has been using typesense for over a year and we use it to store most of our website data 🙂
    f
    • 2
    • 2
  • m
    Hi there, we added 200usd credits by mistake. How to get that refunded? We might not be using the cloud. I've already sent email to the support email.
    a
    • 2
    • 1
  • a
    Hi, I am using self hosted typesense (version 30.2) for long time, In this we have 3 collection one has 8 million data without vector , another two collections with 6lac and 3lac data with vector embedding with inbuild openai/text-embedding-3-small embedding. Here we make update(new or update old) in this collection of 6lac almost 25k documents, I am running it for last 1.5 years , there was no latency in upsert but for last 15 days I ma facing upsert issue, disk, memory and cpu are significantly empty. I have tried to optimized hnsw_params (now i have made it 10,120 from default). thread pull is 16. Before I kept 6lac +3lac doc in single collection and now I am keeping 2 collection as hot and cold. after doing this change it was fine for 5 days , again same issue is coming , in 5 days we added 30 k new data point to that collection of 6lac. Please suggest me what should I do
    f
    • 2
    • 3
  • e
    uh oh. JEV would be great for typesense
  • e
    you guys looking at it?
  • e
  • h
    Hey team, we're seeing intermittent 429s on our /multi_search calls against our products collection, cluster eyd3ihcj4o1xkpwbp.a1.typesense.net. Wanted to check with you before assuming it's expected behavior. We went through your docs and confirmed the Server/Search API has no documented rate limit (that's only on the Cloud Cluster Management API, which we're not touching) — so we're not sure what's actually producing these. We also tried reproducing it ourselves: same query, single request and bursts up to 80 fully concurrent requests from one source, and never got a 429 back, always 200. In production though, we do see real 429s on this same endpoint, mostly correlated with high-frequency crawler traffic (Meta's AI crawlers specifically) hitting many product pages in quick succession, alongside normal user traffic. Cluster health (CPU, RAM, search latency) all looks normal in the dashboard when this happens, so it doesn't look like a resource/capacity issue on our end. Could you help us understand: 1. Is there some infra-level rate limiting or abuse protection in front of the search API that isn't in the public docs? 2. Can you check your logs for cluster eyd3ihcj4o1xkpwbp for 429s on /multi_search and tell us what's actually generating them? Happy to share exact timestamps and sample request payloads if useful. Thanks!
    f
    • 2
    • 5
  • k
    Hi All, I'm back after a long time away. I hope you are all doing well, especially John Bosco, oops I mean Jason Bosco. May the former intercede for the latter, and for me too! We have migrated our systems and that means that we are migrating Typesense. Unfortunately, I have encountered the following problems when starting Typesense on WSL on Windows 11:
    Copy code
    E20260918 17:00:15.390157  7786 store.h:68] Error while initializing store: IO error: While lock file: /var/lib/typesense/meta/LOCK: Resource temporarily unavailable
E20260918 17:00:15.390187  7786 store.h:70] It seems like the data directory /var/lib/typesense/meta is already being used by another Typesense server.
E20260918 17:00:15.390203  7786 store.h:72] If you are SURE that this is not the case, delete the LOCK file in the data db directory and try again.
    This happens when either typesense-server-0.25.0-amd64.deb or typesense-server-30.2-amd64.deb is installed. Deleting the LOCK file has no effect. I performed all these operations while logged in as root. Would anyone have an idea why this is happening? The command that I use to start the typesense server is /usr/bin/./typesense-server --config=/etc/typesense/typesense-server.ini Any help much appreciated. Thank you!
    a
    • 2
    • 1
  • r
    Copy code
    Hi team 👋 We hit what looks like a serious geopolygon performance regression and
filed it with full analysis + repro: <https://github.com/typesense/typesense/issues/3056>

Short version: point-in-polygon filter (filter_by=geom:(lat,lon) on a geopolygon
field) went from ~1-2ms on v28.0 to ~430-500ms on v30.1 with identical data
(~3M docs, one bbox geopolygon per doc). The cost scales linearly with the number
of geopolygon docs and is independent of the query point — it looks like every
query evaluates the whole polygon index since the v29.0 s2regiontermindexer
refactor (PR #2300). Text search and geopoint radius filters are unaffected.

Our production reverse-geocoding runs on 30.1 (Kubernetes, can't downgrade), so
we're really feeling this one. Would appreciate any pointer on:
• whether this is known / already being tracked
• any workaround or config that restores v28-level geo polygon latency on 30.x

Happy to help test a fix or share more profiling data. Thanks! 🙏
    a
    k
    • 3
    • 2