Adapters

Protean provides adapters for four infrastructure ports. Each port ships with an in-memory adapter that is active by default.

For an understanding of the ports and adapters architecture and how it fits into Protean's design, see Ports & Adapters.

Database

The Database port defines the interface for interacting with persistent storage systems. It abstracts the underlying database technology, allowing Protean to support various databases without changing the core application logic.

Each provider declares its capabilities, enabling capability-gated methods and automatic test selection.

Current Implementations:

• Memory - Default in-memory provider (no external dependencies)
• SQLite - File-based relational provider
• PostgreSQL - Production-grade relational provider
• Elasticsearch - Document store for search and analytics

Learn more:

• Database Capabilities - Understanding what each provider can do
• Custom Database Adapters - Create your own database adapters

Broker

The Broker port defines the interface for message brokers and pub/sub systems. It enables communication between different parts of the ecosystem via messages, facilitating asynchronous processing and decoupling.

Note

Protean internally uses an Event Store that acts both as an event storage mechanism as well as a message delivery mechanism within a Protean-based application. Brokers are more focused on integration with other systems.

Current Implementations:

• Inline - In-memory broker for development and testing
• Redis Streams - Durable message streaming with consumer groups
• Redis PubSub - Simple queuing with Redis Lists

Learn more:

• Broker Capabilities - Understanding what each broker can do
• Custom Brokers - Create your own broker adapters

Cache

The Cache port defines the interface for interacting with caching systems. It exposes APIs to temporarily store and retrieve projection data, improving application performance by reducing the need for repeated database access.

Current Implementations:

• Memory - Default in-memory cache (no external dependencies)
• Redis - Persistent distributed cache with TTL support

Event Store

The Event Store port defines the interface for event sourcing and event store systems. It handles the storage and retrieval of events, which are the fundamental units of change in event-driven architectures. This port ensures that all state changes are recorded as a sequence of events, providing a complete audit trail and enabling features like event replay and temporal queries.

Current Implementations:

• Memory - Default in-memory event store (no external dependencies)
• Message DB - PostgreSQL-based production event store

---

Build your own

All adapter types support third-party extensions via Python entry points. See Building Adapters for an overview, or jump directly to Custom Database Adapters or Custom Brokers for detailed guides.