alt.hn

6/10/2026 at 1:45:26 PM

Show HN: Lightweight Task queue on Erlang/OTP, SQLite-backed, no overengineering

 https://github.com/entGriff/ezra

by ent1c3d

6/13/2026 at 2:58:37 PM

Maybe this says more about me than your project, but I find the use of implementing this with the Redis Streams wire protocol very interesting and creative. Being able to leverage the surface area of existing client SDKs should really help adoption and reduce what you have to maintain in order to widely integrate.

I agree that in many areas there often is not much in-between "roll yourself in-memory" and "enterprise grade maxed out scalability focus".

by hankbond

6/14/2026 at 7:54:15 AM

Using the Redis Streams wire protocol means any existing Redis client works without changes. The queue is stored on disk, so tasks survive a restart. No new client library to add. One question: if a worker stops in the middle of a task, does the message go back to the queue for another worker?

by advertum

6/13/2026 at 10:20:37 AM

> This project is maintained by a single author and pull requests are not accepted

Save yourself the headache of people not reading this and just disable pull requests in the repo settings

by bhaney

6/13/2026 at 6:04:15 AM

Oban is really awesome, are you inspired by it?

by neoecos

6/13/2026 at 6:55:45 AM

Title said “no overengineering” so I doubt it.

by skrebbel

6/13/2026 at 9:31:54 AM

I would argue that Oban isn't overengineered.

If so should we also consider PostgreSQL overengineered?

It's a shame OP decided to use Elixir as base, many ecosystems don't have mature task queues (e.g. for Rust I had to roll my own: simple_queue) so the space IMO would be more welcoming.

On OTP doubt anything can even make a dent in Oban user base.

by xlii

6/13/2026 at 10:45:57 AM

Satisfied former Oban user here. Oban is engineered. Your use-case may be petty, though, like your comment.

by gamache

6/13/2026 at 6:21:38 AM

Congrats on the launch. Using the Redis protocol was a pretty clever choice. Does it have to run as a stand-alone server?

by abrookewood

6/13/2026 at 6:13:19 AM

This is nice. For those wanting to stay on Postgres for DAG type of workflows, check out pgmq based PgFlow: https://github.com/agoodway/pgflow

by cpursley

6/11/2026 at 6:58:52 AM

[flagged]

by anapeksha

6/13/2026 at 1:04:58 PM

[flagged]

by volume_tech

6/13/2026 at 6:16:10 AM

good

by tenwz1