# From Single Instance to Split-Brain: A Database Scaling Journey

DevFeed: [From Single Instance to Split-Brain: A Database Scaling Journey](<https://devfeed.tech/articles/from-single-instance-to-split-brain-a-database-scaling-journey-22540.md>)

Original publisher: [Read original article](<https://medium.com/walmartglobaltech/from-single-instance-to-split-brain-a-database-scaling-journey-8b6a27a65023?source=rss----905ea2b3d4d1---4>)

Author: Alok Mishra

Published: 2026-03-31T18:40:52Z

Content type: tutorial

Language: en

Sources: [Walmart Global Tech](<https://devfeed.tech/sources/walmart-global-tech.md>)

Topics: [Databases](<https://devfeed.tech/topics/databases.md>), [Replication](<https://devfeed.tech/topics/replication.md>), [MySQL](<https://devfeed.tech/topics/mysql.md>), [PostgreSQL](<https://devfeed.tech/topics/postgresql.md>), [Self-hosted](<https://devfeed.tech/topics/self-hosted.md>), [backups](<https://devfeed.tech/topics/backups.md>), [Cloud](<https://devfeed.tech/topics/cloud.md>), [Monitoring](<https://devfeed.tech/topics/monitoring.md>), [Amazon EC2](<https://devfeed.tech/topics/amazon-ec2.md>), [Kubernetes](<https://devfeed.tech/topics/kubernetes.md>)

Tags: [architecture](<https://devfeed.tech/tags/architecture.md>), [backups](<https://devfeed.tech/tags/backups.md>), [bare-metal](<https://devfeed.tech/tags/bare-metal.md>), [cloud](<https://devfeed.tech/tags/cloud.md>), [cloud-services](<https://devfeed.tech/tags/cloud-services.md>), [cloud-sql](<https://devfeed.tech/tags/cloud-sql.md>), [cockroachdb](<https://devfeed.tech/tags/cockroachdb.md>), [database](<https://devfeed.tech/tags/database.md>), [ec2](<https://devfeed.tech/tags/ec2.md>), [failover](<https://devfeed.tech/tags/failover.md>), [google](<https://devfeed.tech/tags/google.md>), [google-cloud](<https://devfeed.tech/tags/google-cloud.md>), [google-cloud-sql](<https://devfeed.tech/tags/google-cloud-sql.md>), [kubernetes](<https://devfeed.tech/tags/kubernetes.md>), [monitoring](<https://devfeed.tech/tags/monitoring.md>), [mysql](<https://devfeed.tech/tags/mysql.md>), [postgresql](<https://devfeed.tech/tags/postgresql.md>), [production](<https://devfeed.tech/tags/production.md>), [read-replica](<https://devfeed.tech/tags/read-replica.md>), [recovery](<https://devfeed.tech/tags/recovery.md>), [software-architecture](<https://devfeed.tech/tags/software-architecture.md>), [software-development](<https://devfeed.tech/tags/software-development.md>), [software-engineering](<https://devfeed.tech/tags/software-engineering.md>)

## AI overview

This article explains how database scaling commonly uses a single-leader architecture with asynchronous read replicas. It discusses replication lag, stale reads, split-brain risks, read/write traffic separation, and the operational responsibilities of self-managed versus fully managed database services.

## Source excerpt

I used to think adding a 'Read Replica' was a magic button for scaling applications. I was wrong. While splitting read and write traffic is a standard system design pattern, implementing it introduces a world of pain - from stale reads to the dreaded Split-Brain problem. Here is how database replication actually works, and how to survive the transition. When people talk about "scaling databases" or "adding read replicas", they are almost always thinking about one specific architecture: Single-leader (Primary-Replica) architecture with asynchronous replication This is the architecture used by: MySQL + replicas PostgreSQL + streaming replication Google Cloud SQL PlanetScale, Neon, Supabase, etc. There is exactly one node that accepts writes -> called the Primary (or Leader/Master). All other nodes are Read Replicas -> they apply changes from the primary as fast as they can, but always with some delay (replication lag). This is the default and dominant model in 99% of applications today. Alternative architectures exist (multi-primary, leaderless, CRDTs, etc.), but they are rare and come with their own very different trade-offs. The second axis that actually matters in practice is: Who manages the replicas and failover for you?1. Self-hosted / Self-managed You run MySQL or PostgreSQL yourself (on EC2, Kubernetes, bare metal, etc.). You are 100% responsible for: Setting up replication Promoting a new primary when the old one dies Routing traffic correctly Handling replication lag Monitoring, backups, point-in-time recovery, etc. 2. Fully-managed cloud services RDS, Aurora, PlanetScale, Neon, Supabase, CockroachDB, Spanner, YugabyteDB, etc. The provider gives you a single connection string (or two: one for writes, one for reads) and magically keeps it pointing to healthy nodes, handles failover in seconds, and often hides (or eliminates) replication lag headaches. This second axis is the one that determines how much pain you will actually feel in production. Now, suppose yo