Using DatabaseSessionService

Google Cloud Build with AI Agents
1

Agents built with ADK use SessionService to store session data, along with events, state, etc. By default, agents use VertexAiSessionService implementation, in local development environment, InMemorySessionService can be utilised. The DatabaseSessionService is available as well, allowing to store session data in a relational DB, see https://google.github.io/adk-docs/sessions/session/#sessionservice-implementations

Regarding the DatabaseSessionService, does anyone know about the following:

  • Can multiple, separately deployed agents be pointed to the same DB instance? Would it be recommended to separate them by schemas/namespaces?

  • Do sessions ever expire or are deleted? How reliable is the session storage?

  • When the schema evolves, will an updated agent (with later version of ADK) be able to migrate the schema without interrupting existing instances, potentially on older ADK/schema?

    • I tested this with a locally running agent and a locally running DB (Postgres) - there is no migration table and if there is an existing table, there is no check for schema correctness, the agent starts up with no problems but fails later when trying to access the pre-existing table with incorrect schema.
2

The latest updates to Vertex AI and Agent Builder have made session management and conversational context handling much easier. Now, you can configure the session TTL (Time-To-Live) to fit your needs, allowing you to control exactly how long context data is retained. The system automatically manages session expiration and cleanup, and you can choose your preferred storage implementation—including relational databases with DatabaseSessionService.

Regarding reliability, session handling is now much more robust and configurable, and the official documentation outlines best practices for agent isolation (e.g., using separate namespaces or schemas if multiple agents share a database). Also, database schema migrations should still be planned carefully, but newer releases provide stronger support for integrating agent and session updates.

This approach offers greater flexibility and minimizes manual issues with context, cleanup, and scalability for multi-agent production environments.