Hey so I want to add read replicas, or some sort of global CDN to my open source instance of typesense to make performance for my users globally better. Basically I have a ton of data (around 60GB) so currently I have this on a hetzner box for around 120 euro p/m which is like 5-10x less than cloud providers. So this works for me financially, however I want to get latency really lowered down with read replicas or a CDN approach. My workflow is extreemly read heavy, infact I will only really write in batch jobs a couple of times a month. Any ideas of how I go could go about this with the OSS route or am I best just literally buying two boxes, and applying writes to both boxes when they need them. Bare in mind this will X my cost per read replica as I assume I'll need to have a VM with 64gb of ram for each instance.

A multi-node clustered setup in Typesense requires a minimum of 3 nodes for quorum. So if cost is a constraint, and especially given your minimal writes, you could just spin up two standalone instances and do dual writes to each.

Thank you @Jason Bosco just to follow up. I'm using cloudflare workers so all my api requests are distributed. most of my customers are uk / us. So I was thinking of just spinning up a box in london and somewhere near san francisco for example. One other idea I had was just adding a redis cache for queries to speed up common reads. Is there any way to reduce my ram requirements per box? (as this would make the decision alot easier financially) I have about 60gb of data and I believe you need to mirror that with ram with typesense.

With a 60GB dataset, I would imagine that your cache hit ratio would be low. But if that's not the case and you have a few queries that are commonly accessed, then even an HTTP-based CDN cache would be helpful, instead of having to introduce redis as a cache

Hey @Jason Bosco so my app is a diet and nutrition one but with ai logging essentially the ai takes a natural language description or photo of food "a carbonara, two glasses of red wine, and a chocolate mousse" it turns this into three queries "spagetti" "red wine" "chocolate mousse" which I'm currently using a federated search (where I query for all three a the same time in one request) but perhaps it would be better to do this as a Promise.all with the three seperated queries as Im more likely to get cache hits that way e.g. coffee vs coffee and orange juice (federated) hope that makes sense. Do you think this approach makes the most sense or am I going to lose alot by spamming typesense with additional requests vs batching in a federated. And would you recommend over the other redis vs cloudflare approach? (I'm using cloudflare workers already but upstash and stuff like is pretty easy and cheap to setup so wouldn't be a problem either)

but perhaps it would be better to do this as a Promise.all with the three seperated queries as Im more likely to get cache hits that way

Yeah, from a caching perspective, you might want to separate the query for each ingredient in a separate single-search request, instead of using multi-search.

I guess I'm thinking that cloudflare workers cache will be next to the user, and also yeah (minor benefit tbh as I think my server will have a ton of compute for the amount of requests, as my data size is the main issue so I'll have a load of spare CPU) is it will reduce a bit of load off of typesense too and really typesense is so fast in general (also in-memory) as you say that the main thing is the trip to the server