Add Database Storage Support for Team Collaboration

[alioshr]

Is your feature request related to a problem? Please describe.
Currently, the memory bank server uses file-based storage, which limits collaboration as each developer has their own local copy. This makes it difficult for teams to maintain a consistent knowledge base and share insights effectively.

Describe the solution you'd like
Implement database storage options while maintaining the existing file-based implementation. This would enable:

• Shared access to memory banks across team members
• Consistent knowledge base across the development team
• Reliable concurrent access to memory bank data

The solution would leverage database-specific adapters that handle their own optimized implementations:

// Each database type implements its optimal data access patterns
interface MongoDBOperations {
  findProjects(): Promise<Array<{ name: string }>>;
  findProjectFiles(projectId: ObjectId): Promise<Array<{ fileName: string }>>;
  findFileContent(query: { projectId: ObjectId, fileName: string }): Promise<string>;
  insertFile(doc: { projectId: ObjectId, fileName: string, content: string }): Promise<void>;
  replaceFile(query: { projectId: ObjectId, fileName: string }, content: string): Promise<void>;
}

interface PostgresOperations {
  queryProjects(): Promise<Array<{ project_name: string }>>;
  queryProjectFiles(project_id: number): Promise<Array<{ file_name: string }>>;
  queryFileContent(project_id: number, file_name: string): Promise<string>;
  insertFileRecord(project_id: number, file_name: string, content: string): Promise<void>;
  updateFileRecord(project_id: number, file_name: string, content: string): Promise<void>;
}

Describe alternatives you've considered

• Using a distributed file system
• Implementing Git-based storage
• Using a simple key-value store
• Setting up a centralized file server

Memory Bank Impact

• Project isolation/security

  • Storage-independent security model
  • Each storage implementation handles its own security concerns
  • Configuration-based access control

• Memory bank file structure

  • Maintains consistent interface regardless of storage
  • Each storage type implements its optimal data structure
  • Implementation details isolated to specific handlers

• MCP tool interactions

  • Storage type determined by configuration
  • FileSystem remains default for backward compatibility
  • Database options enable shared access
  • Tools adapt automatically to configured storage type
  • Clean separation between different storage implementations

• User workflow

  • Transparent storage switching through configuration
  • No changes to user interaction model
  • Team sharing enabled through database configuration

• Configuration requirements

interface EnvConfig {
  DB_TYPE: 'FileSystem' | 'MongoDB' | 'PostgreSQL' | 'Redis';
  DB_CONNECTION_STRING?: string;
  DB_AUTH_KEY?: string;
  MEMORY_BANK_ROOT?: string;
}

{
  "allpepper-memory-bank": {
    "command": "npx",
    "args": ["-y", "@allpepper/memory-bank-mcp"],
    "env": {
      "DB_TYPE": "FileSystem",
      "MEMORY_BANK_ROOT": "/path/to/memory-bank"
    }
  }
}

{
  "allpepper-memory-bank": {
    "command": "npx",
    "args": ["-y", "@allpepper/memory-bank-mcp"],
    "env": {
      "DB_TYPE": "MongoDB",
      "DB_CONNECTION_STRING": "mongodb://localhost:27017/memory_bank",
      "DB_AUTH_KEY": "optional-auth-key"
    }
  }
}

Additional context
The storage architecture treats each implementation as a first-class citizen, with FileSystem being just another storage type. This allows each implementation to optimize for its specific characteristics while maintaining a clean separation of concerns. The configuration-based approach makes it easy to switch between storage types and add new ones in the future.