Hey all, we’re looking at redoing a large search t...
# community-helpt
Todd Tarsi
04/09/2025, 3:35 PMHey all, we’re looking at redoing a large search table with many customers, with probably around 150 columns or so in total. However, each org will only use about 25 columns each. In a situation like this, will there be a performance drain from the columns being empty about 80% of the time or so? Should this be like one collection per customer and all of the columns are pretty much always populated, or will the performance be matched in a consolidated table? Will cost be equivalent, or will there be a specific winner here from a cost perspective? Thank you for your time and expertise.
k
Kishore Nallan
04/10/2025, 3:41 AM150 optional fields should be fine. Sparsity should not be a problem here.
t
Todd Tarsi
04/10/2025, 6:35 AMThank you!
Todd Tarsi
04/10/2025, 7:17 PM@Kishore Nallan - Does this hit a top end somewhere? How about 400 sparse fields populated 10% of the time?
Also, one more performance question (sorry to have so many, we’re increasing our Typesense footprint and I want to be cautious about how I use it), when doing an emplace style import, is there a noticable performance hit if I provide the full record but only one field is changed, vs providing just the changed field and id? I am considering pulling the records, diffing, and uploading minimum changeset vs always sending the full record up.