first question is have you noticed any degredation in performance

with your currennt approach?

indices + pagination

i mean pagination isnt really one lol

have you measured any performance issues?

99% of the time your approach is the recommended way

if it's join heavy you can try denormalizing your data

not yet but im building a search heavy app. using turso so im hoping itll hold up since ive read sqlite is pretty decent at reads

oh yeah you'll be fine

not too join heaving. about 3-4 joins max

honestly i wouldnt worry about it until you have some accurate measurements that search is slow

but to answer your question

When a search implenentation uses purely your db for look ups becomes a bottle-neck

people often maintain a seperate search service

which is basically a denormalized data, indices, and more search friendly / performant data-storage and lookups optimized for search scenarios

typesense is just one of many search services

I would always recommend trying to optimize your db lookups first

before adopting one of these

you said you're building a search heavy app, if search is mission critical and you can determine that doing it purely in your db isnt the way to go, then consider using something like typesense from the very beginning (but think long and hard)

the only way to know if your current approach is performant or not

is by populating your database with a fake data-set

with thousands / millions of records

and then gathering metrics while running in production

oh shiet yea that makes sense. gonna look into this as a backup then thanks. for now it seems like dont fix whats not broke?

exactly