4 ms·

If you want to only use sqlite, I suggest looking into litestack: https://github.com/oldmoe/litestack https://github.com/oldmoe/litestack I've not used it myse

If you want to only use sqlite, I suggest looking into litestack: https://github.com/oldmoe/litestack https://github.com/oldmoe/litestack I've not used it myself, but I am going to rewrite one of my projects that I only use locally from postgres to litestack. The benchmarks are incredible! https://github.com/oldmoe/litestack/blob/master/BENCHMARKS.md https://github.com/oldmoe/litestack/blob/master/BENCHMARKS.m...

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 ago
  Litestack provides numerous benefits, but the largest is live replication to S3-compatible storage, which SQLite will not do by default.
  - tillcarlos 2y ago
    Are 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 ago
      Ahh, yeah you’re right. My bad. Litestream was what I was thinking of.
- mosselman 2y ago
  Very 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.

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 ago
Litestack provides numerous benefits, but the largest is live replication to S3-compatible storage, which SQLite will not do by default.
- tillcarlos 2y ago
  Are 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 ago
    Ahh, yeah you’re right. My bad. Litestream was what I was thinking of.
mosselman 2y ago
Very 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.