Ah, very nice to see others exploring that area, too! I think baking the index as immutable object into the deployment package works great for use cases like p

Ah, very nice to see others exploring that area, too! I think baking the index as immutable object into the deployment package works great for use cases like personal blogs, which get updated only every so often, so you can afford rebuilding the search service when doing so. My main motivation for that is security, that way my entire service is read-only and immutable. I definitely want to automate the deployment. My blog sources are on GitHub too (and already auto-published to GitHub Pages when pushing a change), so it shouldn't be too difficult to have another GitHub Action which rebuilds and deploys the search service. Re memory, I run with 512 MB. The app is fine with much less; 128 MB works, too. But Lambda allocates CPU shares proportionally to the assigned RAM and below 512 MB it's just a bit too slow. As I'll probably never leave the free tier with this service, "wasting" memory that way doesn't cost me anything really, altough I feel the RAM/CPU correlation isn't ideal in general, because it seems you'll end up paying for superfluous RAM if you're only actually after lower request latency by means of more CPU cycles.