Hacker News Reader

Comment by PanMan | Hacker News Reader

Correct me if I’m wrong but: SQLite sounds like: runs on one server. While that will work most of the time, it won’t work 100% of the time. I don’t know the specifics, but I’m fairly sure if a queue server crashes, SQS will keep working, as stuff is redundant. So while it can work in a best case, this (probably) won’t have the same reliability as SQS has..

View on HN

I break it down two ways.

First, the project does not yet have a distributed implementation, you’re correct. Stay tuned!

Second, SQLite is incidental. Data is still stored on disk, just as SQS must be, but I’ve chosen SQLite as the file format for now.

Strictly speaking, SQS does not necessarily store data on disk and being highly available and fault tolerant does not exclude one from operating a completely volatile data store. Indeed, SQLite itself has an in-memory option which, when appropriately architected, could be used as the primary data store for a highly available and fault tolerant queue.

Having said that, I think it is safe to assume that SQS probably stores information to non-volatile storage.

Nice work on the project!

Does this even need to compete feature wise with SQS?

If it faithfully reproduces the SQS Api what could possibly stop me from using this product now (if he ever does hosted) and then switching to SQS if the scale is ever justified?

I'm all for a full suite of solutions targeting the same API. Can I run this thing on a single server with my dashboard app for the 3 person team I'm developing for and all that it cost them is per hour for tech support and server hardware and deloy my multi million user app on SQS but have effectively the same code.

The choice of SQLite is a great one as the distributed sqlite space is also growing. You have things like rqlite (raft+sqlite), and you have cloudservices like CloudFlare D1 which is basically distributed/HA sqlite. Plus you can swap it for basically any other sql database.

Reply on news.ycombinator.com