You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Specify Schema when using DatabaseSessionService #2115
Is your feature request related to a problem? Please describe.
When I'm using google.adk.cli.fast_api to run a multi-agent system and I want to use DatabaseSessionService, I am unable to specify a schema location. Because I already have a table called events and a another called sessions in the public schema, I am unable to use this.
Describe the solution you'd like
Be able to change the default schema for table location from the default public
Describe alternatives you've considered
Considered using AgentEngine w/ VertexAI but didn't want to be locked into the platform
Hi @DeanChensj, to support the schema, i'd suggest to make two changes:
Change 1: Add optional arg "engine" to init() of the DatabaseSessionService. Benefits: Scalable to many agents system because different sessions (of different agent) can share the same connection pool to the same SQL engine. The response time will also be much faster when db connections are reused.
Change 2:For every session manipulation method, keep it within a context which: (a) create the schema if it does not exist. (b) utilize the schema translate map to make operation under the give schema. Benefits: Ensure the designated schema is effective in every operation to allow recycling of db connections.
This enhancement is very critical to enable the SessionService to support different enterprise cases where agents need to work on separate schemas with proper data isolation. Let me know if it sounds fine. I could submit a PR accordingly.
Activity
jeffreyrubi commentedon Jul 30, 2025
Hi @DeanChensj, to support the schema, i'd suggest to make two changes:
Change 1: Add optional arg "engine" to init() of the DatabaseSessionService.
Benefits: Scalable to many agents system because different sessions (of different agent) can share the same connection pool to the same SQL engine. The response time will also be much faster when db connections are reused.
Change 2:For every session manipulation method, keep it within a context which: (a) create the schema if it does not exist. (b) utilize the schema translate map to make operation under the give schema.
Benefits: Ensure the designated schema is effective in every operation to allow recycling of db connections.
This enhancement is very critical to enable the SessionService to support different enterprise cases where agents need to work on separate schemas with proper data isolation. Let me know if it sounds fine. I could submit a PR accordingly.
klateefa commentedon Nov 20, 2025
Hi @dylan-apex We are currently reviewing the request, This feature is under review
Thanks for your patience.
divakaivan commentedon Sep 17, 2026
hey @dylan-apex @jeffreyrubi @klateefa is there a good solution for this? thanks