# cloud-sql Published articles for cloud-sql. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## From Single Instance to Split-Brain: A Database Scaling Journey DevFeed: [From Single Instance to Split-Brain: A Database Scaling Journey]() Original publisher: [Read original article]() Author: Alok Mishra Published: 2026-03-31T18:40:52Z Content type: tutorial Language: en Sources: [Walmart Global Tech]() Topics: [Databases](), [Replication](), [MySQL](), [PostgreSQL](), [Self-hosted](), [backups](), [Cloud](), [Monitoring](), [Amazon EC2](), [Kubernetes]() Tags: [architecture](), [backups](), [bare-metal](), [cloud](), [cloud-services](), [cloud-sql](), [cockroachdb](), [database](), [ec2](), [failover](), [google](), [google-cloud](), [google-cloud-sql](), [kubernetes](), [monitoring](), [mysql](), [postgresql](), [production](), [read-replica](), [recovery](), [software-architecture](), [software-development](), [software-engineering]() ### 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 ## Hosting a fully Serverless Web-Based Postgres Admin Client on GCP using Pgweb, Cloud Run, & IAP DevFeed: [Hosting a fully Serverless Web-Based Postgres Admin Client on GCP using Pgweb, Cloud Run, & IAP]() Original publisher: [Read original article]() Author: Austen Novis Published: 2023-03-06T13:17:20Z Content type: tutorial Language: en Sources: [Engineering at Premise - Medium]() Topics: [Cloud Run](), [PostgreSQL](), [Google Cloud Platform (GCP)](), [Serverless](), [Authentication](), [Command-line interface](), [container]() Tags: [authentication](), [cli](), [cloud-computing](), [cloud-run](), [cloud-sql](), [cloudrun](), [container](), [deploy](), [gcp](), [google-cloud-platform](), [identity-aware-proxy](), [pgweb](), [postgresql](), [serverless](), [vpc]() ### AI overview A tutorial explains how to deploy Pgweb, a Go-based PostgreSQL administration client, as a serverless web application on Google Cloud. It uses Cloud Run, CloudSQL, a CloudSQL connector, Secret Manager, Artifact Registry, and optionally an HTTP load balancer with Identity-Aware Proxy for authentication. ### Source excerpt By Austen Novis, Staff Software Engineer Pgweb example screenshot There are a number of quality Postgres open source administration tools such as pgAdmin or DBeaver, but these tools require a persistent server to run. This means that each user needs to install the tool locally and setup their connections, or you need to host the tool in a cloud server, which can get expensive. A much cheaper alternative is to use Pgweb, a lightweight web-based database explorer for PostgreSQL written in Go, and deploy to Cloud Run. This allows you to utilize a web-based tool, for minimal cost, that can scale for any number of users. We will leverage several Google Cloud Platform services for the complete setup starting with a http load balancer to allow for a custom DNS name as well as enable Identity Aware Proxy (IAP), which is what we will be using for authentication. We will host the service in Cloud Run and connect directly to CloudSQL using a CloudSQL connector. You can bypass the load balancer and IAP if you would like to use username and passwords for authentication. Cloud componentsCloud Setup The first step is setting up your CloudSQL instance. This can be done via terraform or in the GCP console. The main requirement is that you enable a public ip address, which will allow us to use the CloudSQL Auth proxy to connect our Cloud Run instance to our CloudSQL instance. If this is not possible you can still connect to your CloudSQL instance to Cloud Run through a VPC Connector instead. Next we will need to save our database connection credentials in GCP's Secret Manger by creating a new secret called PGWEB_DATABASE_URL in the format of postgres:///DB_NAME?host=/cloudsql/PROJECT:REGION:INSTANCE_NAME&user=DB_USER&password=DB_PASSWORD . Now that we have our CloudSQL instance and connection secret we will deploy our Cloud Run instance using the gcloud cli. First we will need to push the desired Pgweb container to GCP's Artifact Registry, which we can do using the following commands ## GKE in production DevFeed: [GKE in production]() Original publisher: [Read original article]() Author: Carlos Alexandro Becker Published: 2017-07-02T00:00:00Z Content type: tutorial Language: en Sources: [Carlos Becker]() Topics: [Gke](), [Google Cloud Platform (GCP)](), [Kubernetes](), [Amazon Web Services](), [Digital Ocean]() Tags: [aws](), [cloud-sql](), [digitalocean](), [gke](), [google-cloud](), [health-checks](), [heroku](), [ingress](), [kubernetes](), [postfix](), [sendgrid](), [spinnaker]() ### AI overview A developer describes deploying small applications on GKE and lessons learned from moving between AWS and Google Cloud. The article covers SSL with Kubernetes Ingress, email delivery through SendGrid, Cloud SQL access through a sidecar container, and deployment with a shell script or Spinnaker. ### Source excerpt I've been working with DigitalOcean, Heroku and AWS for some years now.