list_sessions() performance degrades significantly with large session counts

[ferponse]

Description

When using DatabaseSessionService.list_sessions() in an application with a growing number of sessions, the method becomes increasingly slow as there is no way to limit or paginate the returned results.

Impact

In our deployment (~5k sessions per app, PostgreSQL backend), list_sessions() takes ~40 seconds to return. This makes it impractical to use in any user-facing endpoint. As sessions accumulate over time, the problem only gets worse.

We initially assumed this was a database tuning issue on our side, but after profiling we confirmed the bottleneck is the unbounded SELECT — all rows are fetched and deserialized into Session objects regardless of how many the caller actually needs.

Expected behavior

list_sessions() should support some form of pagination (page_size / page_token or limit / offset) so that callers can retrieve sessions in manageable chunks. A sensible default (e.g. 20–50 results) would also prevent accidental full-table scans.

Current workaround

We've had to implement our own paginated query directly against the database, bypassing DatabaseSessionService entirely. This works but means we lose the benefits of the service abstraction and have to maintain our own serialization logic.

Related

This looks like the same issue reported in #4621. Adding my experience here as another data point — this is a real blocker for production use cases.

Environment

• google-adk version: 1.27.1
• Python: 3.11
• Database: PostgreSQL (async via asyncpg)
• Deployment: Kubernetes (GKE)