You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm looking for an event store for my modular monolith and I found this project. I was very excited after reading documentation and part of the code (great job btw!), but my application is fully async..
Hi @edubacco. Thank you for raising this async support is something we have on our radar.
To be transparent: this area has not been actively worked on yet. We are still evaluating the best approach for maintaining two parallel APIs (sync and async) while minimising code duplication, and we have not yet settled on a solution we are satisfied with.
Additionally, we have not had any real-world production use cases involving async with our library so far, which has made it difficult to prioritise.
If async support is a must-have for your use case and you are considering adopting the library, we would be happy to prioritise this. It would be very helpful to understand your specific requirements, feel free to share more details here or reach out directly.
After looking around for a while, I realized that my use case is probably quite atypical in the Python ecosystem, so I completely understand your doubts.
To give you more context on my problem, I work with a small but skilled product team, and our modular monolith is expected to live for a long time while evolving quickly. We are introducing events mainly as integration events between different aggregates and domains, to support a decoupled and reactive architecture. We are not doing event sourcing yet, even if some patterns overlap.
The main things that made existing libraries hard to adopt for us are:
the application is fully async
events are not always tied to a single aggregate or stream_id
we often want to consume events through broader cursors/streams spanning multiple domains or event types
postgres is enough for our scale, so we care more about architectural flexibility and evolvability than distributed scaling concerns
In the end, I started building a small event store module directly inside the monolith. It gives us more freedom to model what we need and iterate over time.
So please don’t prioritise async support because of us specifically: we already moved in another direction for now. Still, I’ll definitely keep an eye on the project, who knows in the future.
Congrats on the project and on the open source work!
Activity
edubacco commentedon May 7, 2026
Hi Enforcer, any news on this?
I'm looking for an event store for my modular monolith and I found this project. I was very excited after reading documentation and part of the code (great job btw!), but my application is fully async..
lzukowski commentedon May 14, 2026
Hi @edubacco. Thank you for raising this async support is something we have on our radar.
To be transparent: this area has not been actively worked on yet. We are still evaluating the best approach for maintaining two parallel APIs (sync and async) while minimising code duplication, and we have not yet settled on a solution we are satisfied with.
Additionally, we have not had any real-world production use cases involving async with our library so far, which has made it difficult to prioritise.
If async support is a must-have for your use case and you are considering adopting the library, we would be happy to prioritise this. It would be very helpful to understand your specific requirements, feel free to share more details here or reach out directly.
Thanks again for your interest.
edubacco commentedon May 14, 2026
Hi @lzukowski, thanks for the transparent answer.
After looking around for a while, I realized that my use case is probably quite atypical in the Python ecosystem, so I completely understand your doubts.
To give you more context on my problem, I work with a small but skilled product team, and our modular monolith is expected to live for a long time while evolving quickly. We are introducing events mainly as integration events between different aggregates and domains, to support a decoupled and reactive architecture. We are not doing event sourcing yet, even if some patterns overlap.
The main things that made existing libraries hard to adopt for us are:
In the end, I started building a small event store module directly inside the monolith. It gives us more freedom to model what we need and iterate over time.
So please don’t prioritise async support because of us specifically: we already moved in another direction for now. Still, I’ll definitely keep an eye on the project, who knows in the future.
Congrats on the project and on the open source work!