Why not use LocalStack? It has SQS and a lot of AWS services for testing/development. Well documented, open source. https://docs.localstack.cloud/overview/
I think the vibe might be that this is something someone could use for production.
Show HN: Drop-in SQS replacement based on SQLite
81–90 of 171 posts
Re: Show HN: Drop-in SQS replacement based on SQLite
#82Why not use LocalStack? It has SQS and a lot of AWS services for testing/development. Well documented, open source. https://docs.localstack.cloud/overview/
At the very least, I'm guessing this performs better since it's written in Golang.
Re: Show HN: Drop-in SQS replacement based on SQLite
#83I may be asking a naive question, but what is the rationale behind disabling foreign key support and using them anyway in the database schema? See https://github.com/poundifdef/SmoothMQ/blob/46f8b22/queue/sq... The "TODO: check for errors" comment, combined with what seems like disabling foreign key constraint checks, makes me a bit hesitant to try this out.
Good question. It was an evolution. Originally I enforced foreign keys, but inserts/updates were unbearably slow. So I updated the connection string to disable them (but, as you point out, I haven't updated the CREATE TABLE statements.) In practice, I did not find they were necessary - I was only using foreign keys to automatically CASCADE deletes when messages were removed. But instead of relying on sqlite to do tha…
Some of the slowdown will come from not indexing the FK columns themselves, as they need to be searched during updates / deletes to check the constraints.
Re: Show HN: Drop-in SQS replacement based on SQLite
#84One quick suggestion on project structure: Move all the structs from models/ into the root directory. This allow users of this package to have nice and short names like: q.Message and q.Queue, and avoids import naming conflicts if the user has its own „models“ package.
Actually, the "model/" (note: singular form) directory (package model) would be preferred in the golang world.
Re: Show HN: Drop-in SQS replacement based on SQLite
#85[flagged]
The purpose of Show HN is not really ‘product catalogue’
i didnt ask for a product catalogue, all im asking is to clarify whether you are truly FOSS or not by being transparent about the license.
Any type of licensing conditions like AGPL 3.0 to force you to share your code is a no go for many many companies.
I understand the desire to make money and you can do that without AGPL 3.0
Re: Show HN: Drop-in SQS replacement based on SQLite
#86> In terms of monetization, the goal is to just have a hosted queue system. I believe this can be cheaper than SQS without sacrificing performance. Just as Backblaze and Minio have had success competing in the S3 space, I wanted to take a crack at queues. are you monetizing this as a separate business from: https://www.ycombinator.com/companies/scratch-data
What's the point of AGPL though? The enterprises with the budget for self hosting this sort of software usually have requirements and scale beyond what SQLite can offer out of the box.
He's going to make backends pluggable. So other more scalable backends than sqlite could work
Re: Show HN: Drop-in SQS replacement based on SQLite
#87Earlier quoted context omitted.
What's the point of AGPL though? The enterprises with the budget for self hosting this sort of software usually have requirements and scale beyond what SQLite can offer out of the box.
He's going to make backends pluggable. So other more scalable backends than sqlite could work
In practice, I don’t plan on adding an entire proprietary layer - that is just way too much work, and it defeats the purpose. If the open source code has bad performance, why would someone even bother with a hosted version? Like, I want people to be so impressed by the open source code that they’d trust a cloud version to be even better. Clickhouse and duckdb do this very well.
The main difference I expect with a hosted solution are things like multiple tenants or billing integrations. These aren’t core to the product and only necessary when you need to host someone else’s data.
Re: Show HN: Drop-in SQS replacement based on SQLite
#88There is a lot of new ecosystem being built around SQLite in the browser using wasm, as a primary data store or as a local replica for every client, and there are some interesting interactions with crdt and peer to peer applications; does this fit into your business case? Would be interesting to see a massively distributed - via browser embedding - queue, that even uses standard sqs bindings.
Re: Show HN: Drop-in SQS replacement based on SQLite
#89Earlier quoted context omitted.
The purpose of Show HN is not really ‘product catalogue’
i didnt ask for a product catalogue, all im asking is to clarify whether you are truly FOSS or not by being transparent about the license. Any type of licensing conditions like AGPL 3.0 to force you to share your code is a no go for many many companies. I understand the desire to make money and you can do that without AGPL 3.0
It's right there in the LICENSE file: https://github.com/poundifdef/SmoothMQ/blob/main/LICENSE
What's unclear or not transparent about that?
Re: Show HN: Drop-in SQS replacement based on SQLite
#90Good, we need open implementations of all the AWS stuff. I swear they reimplement stuff we have just so there are more places to bill us.
SQS is cheap. 10m requests for $4. You will need hundreds of millions of requests per month for it to be noticable. And can an implementation like this even help you at that point?
Not just cheap per message, but queues themselves are free so there is zero “reserved” cost - it’s pay per message.
Add to that, it’s enormously scalable in terms of throughput and retained messages.
And it’s globally available.
A single file app is no comparison, really. The value of SQS is in the engineering.