Max amount of persistent subscriptions

EventStoreDB
1

Hi!

I was just wondering if there is any limit to the amount of persistent subscription you can have active?

The reason I am asking Is I am considering setting up one subscription per message instead of having one persistent subscription for all messages and then dispatching the messages to correct handler with in the application.

With having one subscription per message I can have different settings for different message types.

Is there a maximum amount of subscription I can have active?
Is it a bad idea to have many subscriptions active?

Thanks for any advice I can get!

2

there is no hard limit at the DB level , maybe at the connection level .

though keep in mind that this will impact the server that will need to handle checkpoints , timouts , retries, parked message for every single

I would suggest you test it out if the number of events type is low that could work.
also worth , if it’s single types you’re looking at : subscribe to the event type streams : https://developers.eventstore.com/server/v22.10/projections.html#by-event-type

1 Like
3

I find persistent subscription only useful when combining it with a broker.

4

that makes sense thank you for your answer!

5

I thought I could get away with using eventstoredb for handling messages, I am using a broker for publishing external messages but internally I’m only using subscriptions. Can you elaborate on how I would combine persistent subscription with a broker?

6

You can avoid the broker but then your question arises about how many persistent subscriptions you can have :slight_smile: ESDB wasn’t designed to be used as a broker, although it’s possible on a relatively small scale.

Can you elaborate on how I would combine persistent subscription with a broker?

Create a subscription that would consume events from ESDB, potentially filter and transform them, then publish to the broker.

1 Like
7

Thank you for your help! using a broker sounds like a good solution for me :slight_smile:

8

A bit late in the discussion, but when combining it with a broker, how would you design it? Simply a single subscriber that forwards esdb to the broker? How could this be scaled? Curious on your thoughts. Cheers!

9

I implemented this by having a background worker that subscribed to esdb and published to a broker.
This background worker also consumed messages from the broker.
I added scaling on cpu for the worker so when the worker consumed a lot of messages cpu would increase and it would scale out and consume more messages from the broker but would also add another subscription to esdb and publish messages to the broker faster.
This worked well for me.