Skip to main content

Overview

elizaOS uses Drizzle ORM with PostgreSQL and automatically handles migrations from your schema definitions. This guide demonstrates how to add custom tables that can be shared across all agents (no agentId field), along with actions to write data and providers to read it.

Database Adapter Interface

Plugins can provide database adapters for custom storage backends. The IDatabaseAdapter interface is extensive, including methods for:
  • Agents, Entities, Components
  • Memories (with embeddings)
  • Rooms, Participants
  • Relationships
  • Tasks
  • Caching
  • Logs
Example database adapter plugin:

Step 1: Define Your Custom Schema

Creating a Shared Table

To create a table that’s accessible by all agents, define it without an agentId field. Here’s an example of a user preferences table:
Key Points:
  • No agentId field means data is shared across all agents
  • elizaOS will automatically create migrations from this schema
  • Use appropriate indexes for query performance

Creating Agent-Specific Tables

For data that should be scoped to individual agents:

Step 2: Create a Repository for Database Access

Repository Pattern

Create a repository class to handle database operations. This follows the pattern used throughout elizaOS:

Advanced Repository Patterns

Transactions

Complex Queries

Step 3: Create an Action to Write Data

Action Structure

Actions process user input and store data using the repository:

Batch Operations Action

Step 4: Create a Provider to Read Data

Provider Structure

Providers make data available to agents during conversations:

Caching Provider

Step 5: Register Your Components

Plugin Configuration

Register your schema, actions, and providers in your plugin:

Important Considerations

1. Database Access Pattern

  • Always access the database through runtime.databaseAdapter.db
  • Use repository classes to encapsulate database operations
  • The database type is already properly typed from the runtime adapter

2. Shared Data Pattern

Without agentId in your tables:
  • All agents can read and write the same data
  • Use userId or other identifiers to scope data appropriately
  • Consider data consistency across multiple agents

3. Type Safety

  • Define interfaces for your domain types
  • Map database rows to domain types in repository methods
  • Handle both camelCase and snake_case field names

4. Error Handling

5. Migration Strategy

Example Flow

  1. User sends message: “I prefer dark theme and Spanish language”
  2. Action triggered:
    • LLM extracts: { theme: 'dark', language: 'es' }
    • Repository stores in database
  3. Provider supplies data:
    • On next interaction, provider fetches preferences
    • Agent context includes: “User Preferences: theme: dark, language: es”
  4. Multiple agents: Any agent can access this user’s preferences

Advanced Patterns

Time-Series Data

Summary

To add custom schema to an elizaOS plugin:
  1. Define schema without agentId for shared data
  2. Create repository classes following elizaOS’s pattern
  3. Create actions to write data using parseKeyValueXml for structure
  4. Create providers to read data and supply to agent context
  5. Register everything in your plugin configuration
elizaOS handles the rest - migrations, database connections, and making your data available across all agents in the system.

See Also

Plugin Components

Learn about Actions, Providers, Evaluators, and Services

Development Guide

Build your first plugin step by step

Common Patterns

Learn proven plugin development patterns

Plugin Reference

Complete API reference for all interfaces