So my guess would be you have both a inverted index and some sort of ANN index deployed, and route queries to those depending on the inferred intent? Could be at least 1 order of magnitude faster though.

Nothing wrong with that though

Mind you in that case a cheap Chromebook with a decent screen would fit the bill

In my mind, "decent screen" is retina-quality display, which limits things. I doubt a cheap Chromebook will have one. The Chromebook Pixel has a 13" retina display option, but why not get an M1 Air and get all the functionality of a real, mainstream OS. (Unless Chromebooks have expanded from minimal Linux using a browser?)

Personally, 15" is about the minimum screen I'll accept if I'm going to do actual work on it, and at that size I expect the choices to be sparse to none. Certainly not cheap.

Yea, I personally think local development is fraught with problems that remote resources solve quite well.

I personally think remote development is fraught with problems that don't exist on local.

Yea it can be picking your own poison in some respects. My preferred workflow is something like spinning up a dedicated dev VM within your provider, install a standard image, then use a local text editor that's saving files over ssh or sftp.

I have found virtually no one has problems with "well I can't get this to run on my machine and here are the n undocumented quirks". Everyone is using a homogeneous environment with local IDE help.

This is in many respects similar to the idea of GitHub codespaces and other remote dev environment tooling that has started to pop up.

While I haven't used any of them, I think the general principle makes a lot of sense. You can also develop on very light local hardware, while taking advantage of an elastic resource depending on what you're doing.

Both can be true at the same time…

Worse case scenario too.

There are just the two of you working on typesense right? Surely having some more people working on the core product (up to five?) should help, no? I'm also building an Algolia alternative, with three engineers including me working on the core engine, and sometimes I wish I had one or two more.

This really resonates with me, I'm currently bootstrapping an Algolia alternative too, albeit with the Saas business model instead of open core. All the best!

I run a Search as a Service startup, would like to sponsor your doc search. Shoot me an email or dm me on twitter @linh_at_anvere

Meilisearch is rather the free and open alternative to Algolia, as it focuses on solving zero-config and easy to deploy autocomplete search, as opposed to analytics at scale.

Did the elasticsearch vs aws fiasco affect your ability to raise, considering it highlighted the risks of the opencore business model?

to be quite honest, it dit not. We are not there yet and if even get to the size of what elastic is today, we would be extremely glad :D

Are you using Opensearch for logging or site search? $371 seems like a lot for a low traffic site. You can probably reduce the cost to a fraction by doing some research on alternatives

It's largely due to the homepage loading a ranked list of items from ES on every request, but I'm probably not optimizing things properly either.

I saw your comment about anvere and looks like you have a background in search/ES? I'd be interested to chat but didn't see a way to contact you!

Hey, send me an email to linh at anvere.net. Or twitter dm @linh_at_anvere edit: anvere is a Search as a Service that I am currently building

Yeah if your low traffic site doesn't need any crazy compute you can probably run it for $5/mo on any commodity VPS provider like Linode or DigitialOcean

Not really a side project, but I haven't quit my job for it so..

I'm building a Search as a Service like Algolia. Currently earning $700 a month from an early customer. Anvere.net

CORS apparently breaks the site for me

What's the size of your index in records?

I run three separate indices at about 10-20mn documents each. But I'm fairly far off any sort of limit (ram and disk-wise I'm at maybe 40%).

I'm confident 100mn is doable with the current code, maybe .5bn if I did some additional space optimization. There are some low hanging fruit that seem very promising. Sorted integers are highly compressable, and right now I'm not doing that at all.

Yes doclist compression is a must. Higher intersection throughput and less bandwidth stress. Are you loading your doclists from persistent storage? What is your current max rps?

I'm loading the data off a memory mapped SSD, trivial questions will probably be answered entirely from memory, although the disk-read performance doesn't seem terrible either.

> What is your current max rps?

It depends on the complexity of the request, and repeated retrievals are cached, so I'm not even sure there is a good answer to this.