8000 [FEATURE] Add Database Session Management · Issue #33 · strands-agents/sdk-python · GitHub
[go: up one dir, main page]

Skip to content

[FEATURE] Add Database Session Management #33

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
puritatemcordis opened this issue May 17, 2025 · 3 comments
Open

[FEATURE] Add Database Session Management #33

puritatemcordis opened this issue May 17, 2025 · 3 comments
Assignees
Labels
enhancement New feature or request

Comments

@puritatemcordis
Copy link

Problem Statement

The current implementation of the Strands agent uses in-memory storage to maintain conversation history. While this is suitable for short-lived sessions, it lacks persistence across application restarts or crashes. To address this limitation, it would be valuable to implement a class that enables saving conversation history to a relational database such as PostgreSQL or MySQL. This enhancement would provide a more robust and reliable foundation for production-grade applications by ensuring conversation state can be preserved and recovered when needed.

Proposed Solution

No response

Use Case

Objective:
Enable the Strands agent to persist conversation history in a relational database to ensure continuity and resilience in production environments.

Primary Actor:
Strands Agent

Stakeholders and Interests:

Developers: Want reliable state management to build robust applications.
End Users: Expect seamless conversation experiences even after interruptions.
Operations/DevOps: Need observability and data recovery mechanisms in case of system failures.
Preconditions:

A relational database (e.g., PostgreSQL, MySQL) is available and configured.
The Strands agent is running in a production or long-lived session environment.

Main Flow:

A user interacts with the Strands agent.
The agent processes user input and generates responses.
Each turn in the conversation (user input and agent response) is saved to the relational database in real-time or at regular intervals.
If the application crashes or restarts, the agent retrieves the saved conversation history from the database.
The agent resumes the conversation with full context, ensuring continuity for the user.

Postconditions:

Conversation history is persistently stored in the database.
The agent can recover and resume sessions after unexpected terminations.

Alternative Flows:

If the database is unreachable, the agent logs the failure and continues with in-memory storage, optionally retrying persistence later.

Alternatives Solutions

No response

Additional Context

No response

@puritatemcordis puritatemcordis added the enhancement New feature or request label May 17, 2025
@puritatemcordis puritatemcordis changed the title [FEATURE] Add class for Database Session Management [FEATURE] Add Database Session Management May 17, 2025
@DennisTraub
Copy link
DennisTraub commented May 20, 2025

Depending on the size of individual messages, particularly if they include multimodal data or large documents, the conversation history can become quite large and difficult to handle for an RDBMS. As an alternative, I would suggest an option to store the history in the local file system with a lightweight lookup index (e.g. a JSON file or SQLLite DB), or an object store like S3, with a lookup table e.g. in DynamoDB.

@vincenzodomina
Copy link

I would definitely need to handle the messages and content blocks (also runs and sessions) as their own tables and records in a relational database (in my case especially for UI use cases and for post processing of results)

My current approach is to store short string contents directly in the content block record in a text field and store multimodal content inputs (images, files or larger texts) as files in S3 and reference them from the content block record. To distinguish small messages from file contents i work with the concept of artifacts (which are then stored as files)

That way the complete chat history can be persisted and retrieved in a performant way without loosing the structure and integrity of the RDB

@zastrowm
Copy link
Member

Thanks for the request & use-case.

I think this might fit in with #57 and is something we're looking into how to better support. We don't have any updates to share yet, but our upcoming roadmap should provide more clarity on improvements to this area.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

5 participants
0