For development, perhaps. For production, absolutely not.
I wish HN had some bot that would just delete any comment from people recommending installing databases. Because 99.9% of the time it's from those who have no experience in running one in a Production environment. Keeping it secure and ensuring backup/restore cycle works is seriously non-trivial.
Would love to know how running a database is considerably less work than adding a library to your existing app.
I think if you're past pgvector performance you won't be listening to a random guy talking about pgvector but have a good understanding of the space.
If you're new (like I was a few months ago) save yourself the time I wasted on the noobtraps I mentioned. It scales way better than the OpenAI API for my use cases.
Lucene (or rather elastic/open search) is way overkill for my needs
Managed Postgres is a thing, probably much more common than managed lucerne. I can name three managed Postgres providers off the top of my head (AWS, Vultr, Supabase).
There are search engines e.g. Solr, ElasticSearch but those aren't what this paper is proposing.
To be clear I object to this:
> I wish HN had some bot that would just delete any comment from people recommending installing databases.
Most applications already use a database. Pooh-poohing Postgres as a solution is silly. For many people, it’s actually going to be less complex to take to production than installing a library, especially one with its own complex storage needs.
Also: technically, isn’t Lucerne a database?