multi-database-and-replicas

What problem does it solve?

Rails applications frequently suffer from slow read performance, read-after-write inconsistencies from unmanaged replica lag, and inefficient database architecture choices like premature sharding or mixing high-load analytics workloads with user-facing queries. AI coding agents often implement incorrect multi-database patterns, leading to production bugs and scalability bottlenecks.

Core Features & Use Cases

• Primary + Replica Configuration: Set up read replicas for read scaling with proper connects_to setup and automatic role switching.
• Concern Isolation: Separate analytics, caching, and compliance-sensitive workloads into dedicated databases to avoid resource contention.
• Replica Lag Management: Implement health checks and alerting for replica lag to maintain data freshness and prevent stale reads.
• Sharding Guidance: Best practices for horizontal sharding when replicas are no longer sufficient, including shard key design and cross-shard limitation handling.
• Connection Pooling: Configure PgBouncer and Trilogy adapter settings for optimal database connection management in production. Use case: A Rails SaaS app with slow admin dashboard reports can offload analytics queries to a dedicated replica, keeping user-facing reads fast without impacting report accuracy or primary database performance.

Quick Start

Use the multi-database-and-replicas skill to configure a primary read replica with automatic role switching for your Rails application to eliminate read-after-write inconsistencies and improve read throughput.