This gem is a really nice all-in-one setup! \n
(Also worth noting that Rails 8 now supports sqlite for your application database (no more warnings about using it in prod), job queue (active job/solid queue) and cache (solid cache) out of the box.)
Yeah I used the full litestack (and litestream for backups) for my SaaS. Oldmoe is also auper helpful on twitter.
Once Rails 8 came out I switched it all over to the solid* gems which pretty much did the same thing.
Sqlite is awesome in the beginning, especially as there are no extra services to start (I only have a web process and a jobs process), all is sqlite.
Sometimes there are db locking issues (using blazer gem, so I guess that uses a different adapter), and I had to optimize some queries. But that’s about it. The SaaS processes thousands of job daily (mission control gem is awesome) and stable so far.
At one point our DB grew to 16GB because I stored all Api requests. Even then it was still fast (except queries on that api requests table).
Running four sqlites definitely saved me some time which I could use for customer focused things. Highly recommend for MVPs, probably more.
SQLite is great, but the README is a bit disingenuous in not mentioning any of the downsides of using it (e.g. scalability concerns if you go beyond what a single box can handle.)
At what scale would this become a significant concern? While some tech startups aspire to achieve Google-level success, such massive scale is extremely rare in reality. I'm curious about the threshold where issues begin to materialize.
My guess is that they assume the reader is already familiar with sqlite. And "lite" is in the name Litestack. And it says in the second sentence of the description: "It exploits the power and embeddedness of SQLite".
Relevant: Just Use Postgres for Everything [1]
[1]: https://www.amazingcto.com/postgres-for-everything/
Using Postgres is becoming easier with the new Rails Solid [Queue, Cable, Cache] stuff.
And DuckDB's Postgres Extension / Postgres's DuckDB extension!
https://duckdb.org/docs/extensions/postgres.html / https://github.com/duckdb/pg_duckdb
Wow! The performance benchmarks against redis are very interesting.
Considering that Rails 8 gives you Progressive Web Apps out of the box, this is a very competitive setup for a small team.
https://github.com/oldmoe/litestack/blob/master/BENCHMARKS.m...
I think this speaks more to a fundamental issue in ruby’s default redis. How is it only able to do 4k/s sets?
I wish there was a Python project like this
I’ve used this for a side project. Coupled with Litestream for backups it’s awesome.
I would 100% recommend.
This gem is a really nice all-in-one setup! \n (Also worth noting that Rails 8 now supports sqlite for your application database (no more warnings about using it in prod), job queue (active job/solid queue) and cache (solid cache) out of the box.)
THIS!
Litestack seems great and probably partially paved the way for similar functionality directly in Rails 8 with the new solid* gems.
Those plus litestream are a treat
This looks great!
Is anyone familiar with something similar for Python in general and Django in particular?
also interested!
Main-Main Replication: LiteFS
Streaming Backups: LiteStream
Just missing logs and, well, for me, graph database.
Yeah I used the full litestack (and litestream for backups) for my SaaS. Oldmoe is also auper helpful on twitter.
Once Rails 8 came out I switched it all over to the solid* gems which pretty much did the same thing.
Sqlite is awesome in the beginning, especially as there are no extra services to start (I only have a web process and a jobs process), all is sqlite.
Sometimes there are db locking issues (using blazer gem, so I guess that uses a different adapter), and I had to optimize some queries. But that’s about it. The SaaS processes thousands of job daily (mission control gem is awesome) and stable so far.
At one point our DB grew to 16GB because I stored all Api requests. Even then it was still fast (except queries on that api requests table).
Running four sqlites definitely saved me some time which I could use for customer focused things. Highly recommend for MVPs, probably more.
Looks fantastic!
SQLite is great, but the README is a bit disingenuous in not mentioning any of the downsides of using it (e.g. scalability concerns if you go beyond what a single box can handle.)
At what scale would this become a significant concern? While some tech startups aspire to achieve Google-level success, such massive scale is extremely rare in reality. I'm curious about the threshold where issues begin to materialize.
> README is a bit disingenuous
My guess is that they assume the reader is already familiar with sqlite. And "lite" is in the name Litestack. And it says in the second sentence of the description: "It exploits the power and embeddedness of SQLite".
Personally I think that's good enough.
Gorgeous, bookmarked it!
Lol sorry but if you are going to claim to be a faster cache than redis you need to bring receipts
True for any performance claim, in any library, in any language.
SQLite operates in the same process as the app. No network overhead, no socket overhead, etc.
The tradeoff is all your eggs in one basket, so to speak.
Very interesting