Skip to main content

Overview

By default, KnowledgeBase stores document chunks only in the vector database. When you pass a storage backend, KnowledgeBase also writes a document registry — a relational record of every document it has processed, including metadata, content hashes, chunk counts, and processing status. This is useful when you need to:
  • Track which documents are indexed across restarts without querying the vector database
  • Share a storage backend between Memory and KnowledgeBase for a unified persistence layer
  • Audit document lifecycle — see when documents were added, their status, and source paths
  • Enable source removal by document ID — storage lets remove_document() look up the original file path and clean up sources

Quick Start

Pass any Upsonic storage backend as the storage parameter:
After setup(), every processed document is recorded in the storage’s knowledge table (upsonic_knowledge by default). When you call add_source(), add_text(), or remove_document(), the registry is updated automatically.

What Gets Persisted

Each processed document creates a row in the knowledge table: See Storage Tables for the full schema.

Supported Backends

Any Upsonic storage backend works — the same ones used for Memory: Async storage backends (AsyncSqliteStorage, AsyncPostgresStorage, AsyncMongoStorage, AsyncMem0Storage) are also supported.

Sharing Storage with Memory

You can use the same storage instance for both Memory and KnowledgeBase. Each system writes to its own tables:

Custom Table Name

Override the default knowledge table name via the storage constructor: