Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for valkey instead of Redis #141

Open
matvp91 opened this issue Dec 9, 2024 · 2 comments
Open

Support for valkey instead of Redis #141

matvp91 opened this issue Dec 9, 2024 · 2 comments

Comments

@matvp91
Copy link
Collaborator

matvp91 commented Dec 9, 2024

Is your feature request related to a problem? Please describe.
The job orchestrator relies on BullMQ, which is tightly coupled with Redis. With the latest Redis debacle, we might take a look if we can move to valkey (https://github.com/valkey-io/valkey) entirely.

Describe the solution you'd like
Investigate if valkey is feasable.

Additional context
BullMQ seems compatible, see taskforcesh/bullmq#2642 and https://x.com/manast/status/1841042438510494090, thus API and Artisan shall be compatible too.

For Stitcher, we can add a new adapter and rely on env variables specifically for valkey. Or we can re-use REDIS_HOST and REDIS_PORT but use a different KV store underneath.

@volyx
Copy link

volyx commented Jan 2, 2025

Thank you for this awesome project! I was wondering if a Postgres table could be used as a queue instead of Redis/valkey. I've heard that Postgres is often used in this way (for example, here's a random link from the internet: https://news.ycombinator.com/item?id=39315833).

@matvp91
Copy link
Collaborator Author

matvp91 commented Jan 3, 2025

BullMQ is heavily integrated in Superstreamer to orchestrate the queue / workers, moving to Postgres would have us drop BullMQ and write our own scheduler. Not quiet sure I see a benefit in that.

Nonetheless, Postgres is great though!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants