Decoupling RADIUS Auth/Acct and Moving Toward SQL-less Accounting
Hi, I would like to get your input on a structural change we are planning. In our current setup, we have 8 RADIUS instances handling both Authentication (Auth) and Accounting (Acct) on the same server, utilizing PostgreSQL as the storage backend. We are planning to migrate to a scenario where we decouple these responsibilities into dedicated RADIUS instances for Auth and Acct. Currently, we store only the latest sessions in RadAcct to support functions like simultaneous-use. The rest of the accounting data is generally forwarded through RADIUS to a Kafka server. My goal is to eliminate SQL from the accounting process entirely. Ideally, I want to forward incoming accounting packets directly to Kafka and immediately return a response. I can find a workaround for maintaining session states without writing them to SQL, but I am stuck on how to manage IP pool (ippool) operations efficiently. It seems there might be no way to avoid using a database for IP management, and it might not even be logical to do so, but I wanted to hear your perspective on this. Looking forward to your thoughts. Best regards,
On Jan 13, 2026, at 7:27 AM, Erdal Emlik via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
In our current setup, we have 8 RADIUS instances handling both Authentication (Auth) and Accounting (Acct) on the same server, utilizing PostgreSQL as the storage backend. We are planning to migrate to a scenario where we decouple these responsibilities into dedicated RADIUS instances for Auth and Acct.
That's a reasonable design.
Currently, we store only the latest sessions in RadAcct to support functions like simultaneous-use. The rest of the accounting data is generally forwarded through RADIUS to a Kafka server.
OK.
My goal is to eliminate SQL from the accounting process entirely.
Why?
Ideally, I want to forward incoming accounting packets directly to Kafka and immediately return a response. I can find a workaround for maintaining session states without writing them to SQL, but I am stuck on how to manage IP pool (ippool) operations efficiently.
Kafka is really a logging framework. It's not a database. Maintaining session state requires a database. Maintain IP pools requires a database.
It seems there might be no way to avoid using a database for IP management, and it might not even be logical to do so, but I wanted to hear your perspective on this.
Use a database. If you don't like SQL, switch to Redis. But it's hard to maintain a database of IP pool without using an actual database. Alan DeKok.
On 14 Jan 2026 at 1:27:15 AM, Erdal Emlik via Freeradius-Users < freeradius-users@lists.freeradius.org> wrote:
It seems there might be no way to avoid using a database for IP management, and it might not even be logical to do so, but I wanted to hear your perspective on this.
Looking forward to your thoughts.
Do you actually need dynamic addresses from a centralised pool? Assuming you are in a modern broadband environment, assigning an address at provisioning time is a lot easier, and very much worth considering. -- Nathan Ward
participants (3)
-
Alan DeKok -
Erdal Emlik -
Nathan Ward