Decoupling RADIUS Auth/Acct and Moving Toward SQL-less Accounting

[Alan DeKok]

On Jan 13, 2026, at 7:27 AM, Erdal Emlik via Freeradius-Users <freeradius-users at 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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20260113/9b7e4f33/attachment.sig>