3 ms·

I think the vibe might be that this is something someone could use for production.

• mtndew4brkfst 2y ago
  With no distribution model and built on SQLite, it certainly doesn't scream "production candidate" to me.
  • ku1ik 2y ago
    There’s more production systems on this planet running on a single node than ones running in a distributed setup. And SQLite is a rock solid database, deployed in more places than Postgres. The only thing here that could be taken when weighing production readiness would be the maturity and stability of this project itself.
  • gkbrk 2y ago
    You know there are millions of production deployments of SQLite right? It's perhaps the most widely deployed database.
• mannyv 2y ago
  "Production" is a big word to use for a piece of software. There are different levels of "production ready," depending on what you care about. Some enterprise production questions: * Is it HA? What HA topology is it designed for? * How many messages-per-second can it ingest? * What about with multiple clients? * Can you front-end it via a load balancer? * Can it guarantee only-one delivery? * How does it handle errors? ie: when a message is retrieved by a client and the client errors after the server dies, what happens to the message - does it redrive or expire correctly when the server comes back up? * How does it guarantee consistency in a multi-node environment? * How dies it behave when a node dies/runs out of memory? * How do you monitor it? * How do you recover a corrupted instance? * what happens if/when the SQLite partition runs out of space? etc etc. I use SQS as a main pipeline, and I would want to know a bunch of these things before I'd even consider replacing it. But for someone with one box on a VPS somewhere, you probably only care if it runs for a year without crashing