3 ms·
Is this really necessary given the advances with SQLite in Rails 8? What edge does this have over what’s included these days?
by jherdman 2y ago
Is this really necessary given the advances with SQLite in Rails 8? What edge does this have over what’s included these days?
- adamtaylor_13 2y agoLitestack provides numerous benefits, but the largest is live replication to S3-compatible storage, which SQLite will not do by default.
- tillcarlos 2y agoAre you confusing it with Litestream, the backup solution? https://litestream.io https://litestream.io What they meant was https://github.com/oldmoe/litestack https://github.com/oldmoe/litestack which has a lot of things built on top of sqlite, like job queue and caches. Rails 8 now comes with most of them out of the box. My SaaS ran on litestack until rails 8 came out, then I switched without problems.
- adamtaylor_13 2y agoAhh, yeah you’re right. My bad. Litestream was what I was thinking of.
- mosselman 2y agoVery good question, I don't know. Ideally you'd stick with the most vanilla stack, being solid queue, etc. However after trying solid queue in my production environment with Postgres I was left very disappointed at the reliability and speed. This could've been some misconfiguration on my part though. Another thing that I noticed is that if you compare litestack's benchmarks to solid_cable (for example) litestack claims to outperform redis whereas the argument for solid_queue is that it is slower, but worth the simplicity of 'just using the database': https://github.com/rails/solid_cable?tab=readme-ov-file https://github.com/rails/solid_cable?tab=readme-ov-file All in all I would prefer 'the standard' solution, but I am interested in experimenting with litestack. After all that is what side projects are perfect for.