Executando verificação de segurança...
1

boa noite, sr

muito interessante. eu li a documentação e achei muito massa, pois é uma alternativa essencial inclusive para situações em que a RAM é limitada, assim como processamento está limitado, como num cenário crítico de uma VPS de 1 núcleo, 1GB de RAM. ou até mesmo em uma tv box armbian portando H3 quad core @ 1.2GHz, 2GB RAM e 8GB de armazenamento NAND, fraquinha. eu não teria usado nestjs com bullmq e redis para isso, eu teria usado essa lib. comentei sobre isso em uma postagem sobre sqlite vs postgres.
em cenários críticos, minimalistas, faz todo sentido; combinado com sqlite, fica ideal, mesmo.

Carregando publicação patrocinada...
1

Só pra salientar que SQLite não é muito bom com concorrência. Se for em um caso como esse que você comentou, onde vai ter apenas um nó consumindo dados, maravilha, vai funcionar muito bem mesmo :D

SQLite é o nosso DB de teste btw. Essa facilidade é uma maravilha mesmo.

1

Legal esse caso de uso, não tinha pensado por esse lado! Mas de certa forma ele se conecta com um dos princípios que motivaram o projeto. Quando começamos um side project ou algo pessoal, geralmente temos só um DB e uma instância rodando o app. A ideia era criar algo que não exigisse adicionar nada novo à stack, como Redis, por exemplo. Isso ajuda a reduzir custo e complexidade, sem abrir mão de funcionalidades essenciais.

De fato, usar SQLite em ambientes limitados é uma alternativa interessante, parece ter sido um acerto. Mas, em cenários extremamente restritos, a gente não chegou a rodar benchmarks. Então eu recomendaria configurar o Sidequest com baixa concorrência nas filas e na concorrência global, só por precaução.