# google-cloud-sql

Published articles for google-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 Project Description to Funding Opportunity

DevFeed: [From Project Description to Funding Opportunity](<https://devfeed.tech/articles/from-project-description-to-funding-opportunity-22853.md>)

Original publisher: [Read original article](<https://medium.com/google-developer-experts/from-project-description-to-funding-opportunity-16c2b3b8ffb5?source=rss----a67bd6fa7d58---4>)

Author: Gabriel Preda

Published: 2026-08-31T05:03:07Z

Content type: tutorial

Language: en

Sources: [Google Developer Experts - Medium](<https://devfeed.tech/sources/google-developer-experts-medium.md>)

Topics: [Artificial Intelligence](<https://devfeed.tech/topics/ai.md>), [Google AI](<https://devfeed.tech/topics/google-ai.md>), [Streamlit](<https://devfeed.tech/topics/streamlit.md>), [Cloud](<https://devfeed.tech/topics/cloud.md>), [PostgreSQL](<https://devfeed.tech/topics/postgresql.md>), [postgresql clusters](<https://devfeed.tech/topics/postgresql-clusters.md>)

Tags: [adk](<https://devfeed.tech/tags/adk.md>), [ai](<https://devfeed.tech/tags/ai.md>), [building](<https://devfeed.tech/tags/building.md>), [cloud](<https://devfeed.tech/tags/cloud.md>), [developer](<https://devfeed.tech/tags/developer.md>), [gemini](<https://devfeed.tech/tags/gemini.md>), [google](<https://devfeed.tech/tags/google.md>), [google-adk](<https://devfeed.tech/tags/google-adk.md>), [google-cloud-sql](<https://devfeed.tech/tags/google-cloud-sql.md>), [pgvector](<https://devfeed.tech/tags/pgvector.md>), [postgresql](<https://devfeed.tech/tags/postgresql.md>), [search](<https://devfeed.tech/tags/search.md>), [streamlit](<https://devfeed.tech/tags/streamlit.md>)

### AI overview

This article describes GrantMatch AI, a Streamlit application that matches project descriptions with potentially relevant grant and funding opportunities. It explains how hybrid keyword and embedding search, Gemini, ADK, Cloud SQL, PostgreSQL, pgvector, and Streamlit are used to connect related concepts despite different wording.

### Source excerpt

Building GrantMatch AI with hybrid keyword and embedding search using Gemini, ADK, Cloud SQL, PostgreSQL, pgvector, and Streamlit Continue reading on Google Developer Experts "

## 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