Well my rule is basically - if search functionality is the most essential to your platform and the only other functionality you need otherwise is basic key-value stuff (look up items by user id, stuff like that) then yes, and handle performance issues with your preferred caching solution - redis in my case.

If you need something where money needs to be maintained then you need the security of relational database.

If search is only of secondary importance, use whatever database your prefer to work with and then index that.

But I also have the opinion that as time goes on search becomes a primary functionality of any platform.

Good question! For some toy weather data, Elasticsearch as the only data store made sense. If I were to add more sensors and features and make this a long term project, I'd likely try to wire up some automated backups. If it were some kind of production app that a second human relied on, then I would think hard about the data, the failure scenarios, budget, etc.

Does that answer your question at all?

It depends on what you're doing?

no, no and no

No, not for writing. It's never safe. It will eventually eat your data.

But for reading it's fine. So by all means, you can populate from a main data store that you never otherwise touch.

Then again, if you're running just a single instance on really small data... What could go wrong?

Edit: Again, small stuff, locally, it's probably fine. But ElasticSearch wasn't really built to be a primary data store.

Sources:

https://aphyr.com/posts/332-jepsen-crate-0-54-9-version-dive... (This has links to other good sources, right in the beginning).

https://news.ycombinator.com/item?id=11325316

https://news.ycombinator.com/item?id=11362069