Repository navigation
feat(memory): SQL-backed DatabaseMemoryService with scratchpad for durable agent memory #4735
Description
Activity
- addedservices[Component] This issue is related to runtime services, e.g. sessions, memory, artifacts, etc[Component] This issue is related to runtime services, e.g. sessions, memory, artifacts, etc
on Mar 6, 2026 @Raman369AI Thanks for the update. The request is currently being reviewed, and I will let you know if anything further is needed. Thank you for understanding.
- addedneeds review[Status] The PR/issue is awaiting review from the maintainer[Status] The PR/issue is awaiting review from the maintainer
on Mar 9, 2026 Hi @kronos3610,
Thank you so much for the detailed proposal and for putting so much thought into designing a durable, self-hosted memory solution for ADK. We truly appreciate the effort you took to outline the schema, search backend, and test strategy.
Since this issue was opened, we have added official support for local, durable SQL memory in the core library via
SqliteMemoryService(introduced in #4116, available undergoogle.adk.memory.SqliteMemoryService). It provides file-based SQLite persistence across process restarts, event-level delta ingestion (add_events_to_memory), and full-text search with FTS5 and LIKE fallback—addressing the need for a zero-cloud, self-hosted memory service out of the box.For broader relational database backends (such as PostgreSQL, MySQL, and distributed SQL) and specialized working-memory tools, our team's architectural direction is to keep the core ADK runtime lean and host external database integrations in the
google/adk-python-communityrepository (as discussed in #5339). We would warmly welcome and encourage community packages extendingBaseMemoryServicefor SQLAlchemy backends, and we would be more than happy to feature and link to them in our official integrations documentation.Because the core requirement for self-hosted durable SQL memory is now addressed via
SqliteMemoryService, and broader SQL backends are designated for the community repository, we are closing this issue.Thank you once again for your contribution and for helping make ADK better!
Summary
The ADK currently ships only
InMemoryMemoryService(volatile, keyword-only, test-only) and cloud-specific Vertex AI services. There is no durable, self-hosted memory option for production deployments that do not use Vertex AI.Problem
Developers running ADK agents on-premise or against non-Google cloud providers have no way to persist agent memory across process restarts without writing their own implementation from scratch.
Proposed Solution
Add
DatabaseMemoryService— aBaseMemoryServiceimplementation backed by any SQLAlchemy-supported async database (SQLite, PostgreSQL, MySQL, MariaDB, Spanner via the existing SQLAlchemy adapter).Core features
MemoryEntrywrites are stored in a SQL table (adk_memory_entries) that survives process restartsadd_session_to_memoryis safe to call multiple times (DELETE + re-INSERT)add_events_to_memoryskips already-storedevent_idsMemorySearchBackendABC allows swapping in FTS or vector-embedding backends; ships withKeywordSearchBackend(LIKE/ILIKE, AND-first → OR-fallback)adk_scratchpad_kv) and append-only log (adk_scratchpad_log) for intermediate working memory during task execution, exposed as fourBaseToolsubclasses agents can call directlyZero-config for SQLite
New public API surface
DatabaseMemoryServicegoogle.adk.memoryMemorySearchBackendgoogle.adk.memoryKeywordSearchBackendgoogle.adk.memoryscratchpad_get_toolgoogle.adk.tools.scratchpad_toolscratchpad_set_toolgoogle.adk.tools.scratchpad_toolscratchpad_append_log_toolgoogle.adk.tools.scratchpad_toolscratchpad_get_log_toolgoogle.adk.tools.scratchpad_toolTest coverage
38 unit tests using
sqlite+aiosqlite:///:memory:(no external DB required):BaseMemoryServicemethodsFiles changed
Related
Complements the existing
DatabaseSessionServicewhich follows the same SQLAlchemy async pattern.