Maybe you’re using that for something else, but in general it’s not needed to have a broker. A broker allows other MQTT clients to connect to it. (Assuming your Raspberry Pi can be accessed by those.) One can set up one’s own broker in “bridge” mode to act as a client towards TTN and be a broker for others.
For most use cases (and also for the details you described), just being a client to TTN’s broker suffices. Such client is built-in into Node-RED.
If this means you’re using a Decoder in TTN’s Payload Formats in TTN Console: fine indeed. But beware: Payload available but sometimes not decoded to payload_fields in MQTT.
In fact, the timestamp below the “error occurred” debug node in my screenshot was due to some “Unable to decode payload fields: Internal error: Interrupted javascript execution for Decoder after 120.862081ms”. At the time I created that screenshot that error occurred for 0.5% of the messages (6 out of 1,238 = 0.005, in 15 hours). Note that those uplinks will still be delivered through MQTT (after the two minutes timeout as mentioned in the error message), but without a payload_fields attribute. That’s also why it’s important to subscribe to the .../errors events, to know why payload_fields is missing. (It could also fail due to a programming error, or unexpected data.)
I’d recommend decoding in your application instead of TTN Console.