Cloud SQL PostgreSQL Google: guía 2026 con precios y
Cloud SQL para PostgreSQL es el servicio administrado de Google Cloud que corre instancias PostgreSQL comunitarias en VMs gestionadas, respaldadas por Persistent Disk, con backups automatizados, recuperación punto en tiempo y alta disponibilidad opcional. Según el análisis de Christophe Pettus publicado el 12 de mayo de 2026, es el tercero en su serie de comparativas de PostgreSQL administrado, y lo describe como un “return to first principles” después de la arquitectura distribuida de Aurora.
En 30 segundos
- Cloud SQL para PostgreSQL corre PostgreSQL comunitario en VMs gestionadas por Google, sin acceso directo del usuario a la VM.
- Tiene dos ediciones: Enterprise (la clásica) y Enterprise Plus (mayor performance, SLA del 99.99% incluyendo mantenimiento, Data Cache).
- El failover en alta disponibilidad tarda alrededor de 60 segundos y no requiere cambiar el connection string de la aplicación.
- La retención de logs para recuperación punto en tiempo es de 7 días en Enterprise y 35 días en Enterprise Plus.
- Enterprise Plus cuesta aproximadamente un 20-30% más, pero duplica la performance en escrituras y tiene comportamientos distintos en caché y mantenimiento.
Google es una empresa de tecnología fundada en 1998 por Larry Page y Sergey Brin que desarrolla servicios de búsqueda, publicidad y computación en la nube. Su plataforma Google Cloud incluye servicios como Cloud SQL para bases de datos PostgreSQL gestionadas.
Qué es Cloud SQL para PostgreSQL: arquitectura y componentes
Cloud SQL para PostgreSQL es el servicio de base de datos administrado de Google Cloud que ejecuta PostgreSQL comunitario dentro de una VM gestionada por Google (un Compute Engine al que vos no tenés acceso directo), con un Persistent Disk regional debajo para el almacenamiento de datos.
Ponele que migraste de un servidor propio donde tenías acceso root a la VM, configurabas pg_hba.conf a mano y debugueabas en el filesystem. Con Cloud SQL, nada de eso. El proceso de PostgreSQL corre ahí, pero no es tuyo para tocar: Google maneja el SO, los parches, los backups y el monitoreo. Lo que tenés es un endpoint, una consola, y la API.
La arquitectura es deliberadamente convencional. A diferencia de Aurora (que usa almacenamiento distribuido desacoplado del compute), Cloud SQL es una instancia PostgreSQL contra un disco persistente. Más simple de entender, más predecible en su comportamiento, menos magia invisible. Según la documentación oficial de Google, el aparato de managed service incluye: backups automatizados, recuperación punto en tiempo (PITR), alta disponibilidad opcional, read replicas, ventanas de mantenimiento configurables, y una ruta de conexión integrada con IAM.
El acceso a la instancia pasa por Cloud SQL Auth Proxy o por IP autorizada. IAM puede gestionar la autenticación de usuarios de base de datos, que es cómodo si ya tenés todo en GCP pero puede ser un obstáculo si venís de otro lado.
Ediciones Enterprise vs Enterprise Plus: las diferencias que importan
Acá viene lo bueno, porque es donde Cloud SQL se complica un poco.
Google dividió el servicio en dos ediciones con arquitecturas internas diferentes, no solo distintos niveles de precio. Enterprise es la oferta clásica. Enterprise Plus es la más reciente, con hardware N2 en vez de N1, Data Cache (caché de datos en memoria local para reads frecuentes), mejor SLA y comportamientos distintos en failover y mantenimiento. Según el anuncio oficial de Google, Enterprise Plus incluye 99.99% de SLA que cubre incluso las ventanas de mantenimiento, mientras que Enterprise garantiza 99.95% y el mantenimiento puede interrumpir brevemente la disponibilidad.
| Característica | Enterprise | Enterprise Plus |
|---|---|---|
| Hardware | N1 (generación anterior) | N2 (más reciente) |
| SLA | 99.95% (mantenimiento no incluido) | 99.99% (incluye mantenimiento) |
| Data Cache | No | Sí (caché local en memoria) |
| Retención de logs PITR | Hasta 7 días | Hasta 35 días |
| Performance en writes | Línea base | ~2x mejor |
| Costo relativo | Línea base | ~20-30% más caro |
| Failover HA | ~60 segundos | ~60 segundos (con mejoras en caché) |
La distinción importa porque algunas features que uno lee como “características de Cloud SQL” son exclusivas de Enterprise Plus. Si planificás un sistema de producción crítico y mirás la documentación esperando PITR de 35 días y Data Cache, asegurate de que estás en la edición correcta.
Backups y recuperación ante desastres
Cloud SQL hace backups automatizados diarios por defecto. Los podés programar en una ventana horaria, y retiene un número configurable de backups (hasta 365 con las configuraciones adecuadas). Hasta ahí, estándar. Relacionado: en la automatización de tus deployments.
Lo que diferencia ediciones es el PITR. La recuperación punto en tiempo en Enterprise guarda logs de transacciones por hasta 7 días; en Enterprise Plus, hasta 35 días. El RPO típico es de 5 minutos o menos, lo que significa que si algo explota, podés volver al estado de la base a cualquier momento en ese rango, no solo al momento del último backup.
Para disaster recovery más allá de la región, Cloud SQL soporta réplicas cross-region. ¿Son igual de rápidas que en la misma región? No. ¿Qué pasa si la región primaria se cae? Tenés que promover la réplica manualmente o configurar scripts para hacerlo. No es automático fuera del setup de HA regional.
Alta disponibilidad y failover: cómo funciona
El HA regional de Cloud SQL usa replicación síncrona a Persistent Disk en dos zonas dentro de la misma región. Si la zona primaria falla, Cloud SQL promueve la instancia standby automáticamente en alrededor de 60 segundos.
Lo que me parece bien de este diseño: el connection string no cambia. La aplicación reconecta al mismo endpoint y no sabe que hubo un failover. No necesitás lógica especial del lado del cliente para manejar el cambio de host primario, cosa que en otros setups sí es necesario.
Eso sí: 60 segundos de downtime no es cero downtime. Para cargas que toleran ese gap, funciona. Para las que necesitan sub-segundo, tenés que armar otra estrategia (read replicas para reads, tolerancia a reconexiones, connection pooling con PgBouncer si querés absorber parte de ese bache). Más contexto en dentro del ecosistema de Google Cloud.
¿Y Enterprise Plus hace algo diferente acá? El tiempo de failover es similar, pero el Data Cache mejora la experiencia post-failover porque el read cache local en la nueva instancia primaria se reconstruye más rápido gracias a cómo está diseñado el sistema de caché.
Comparativa: Cloud SQL PostgreSQL vs RDS vs Azure PostgreSQL
Si no estás comprometido con un cloud específico, la comparativa tiene sentido. Según el análisis de Hasura, los tres servicios cubren los casos de uso estándar pero tienen diferencias importantes en precio, integración y características.
| Característica | Cloud SQL PostgreSQL | AWS RDS PostgreSQL | Azure Database for PostgreSQL |
|---|---|---|---|
| Transferencia de datos | Sin cargo adicional (entre servicios GCP) | Cargo por egress | Cargo por egress |
| HA | Regional, 2 zonas, ~60s failover | Multi-AZ, ~30-60s failover | Zone-redundant HA |
| Ediciones/tiers | Enterprise / Enterprise Plus | RDS Standard / RDS Multi-AZ Cluster | Flexible Server |
| Integración nativa | BigQuery, Cloud Run, GKE, Vertex AI | Lambda, ECS, EKS, SageMaker | Azure Functions, AKS, Azure ML |
| PITR máximo | 35 días (Enterprise Plus) | 35 días | 35 días |
| Mejor para | Ecosistema GCP, analytics con BigQuery | Ecosistema AWS, flexibilidad en instancias | Ecosistema Azure, cargas .NET/Windows |
Una ventaja concreta de Cloud SQL que no siempre aparece en comparativas: sin cargo por transferencia de datos entre servicios dentro de GCP. Si tu aplicación corre en Cloud Run o GKE y lee mucho de la base, eso puede ser una diferencia real en la factura mensual. RDS cobra por egress, y con volúmenes altos de tráfico eso suma.
Precios y modelo de costos
Cloud SQL cobra por vCPU, memoria y almacenamiento por separado. El almacenamiento es en Persistent Disk SSD o HDD. La HA duplica el costo de compute (porque estás corriendo dos instancias). Las read replicas cuestan igual que una instancia primaria del mismo tamaño.
Una instancia de 4 vCPU y 16 GB RAM en Enterprise (sin HA) puede rondar USD 200-250/mes dependiendo de la región. Con Enterprise Plus, sumá un 20-30%. Con HA, doblá el compute. Con read replicas, sumá otra instancia. Se acumula rápido si no lo planificás.
Los committed use discounts permiten reservar compute por 1 o 3 años con descuentos que pueden llegar al 25-52%. Si la carga es predecible y estable, aplica. Complementá con en tu stack de DevOps.
Para equipos en Latinoamérica con infraestructura propia en GCP, la ecuación del egress gratuito puede hacer inclinar la balanza versus otros proveedores. Igual, si ya tenés hosting consolidado y necesitás una base administrada, servicios como donweb.com también ofrecen soluciones de cloud administrado que vale la pena evaluar según el contexto.
Cuándo tiene sentido Cloud SQL y cuándo no
Cloud SQL encaja bien si ya estás en GCP. La integración con BigQuery para federated queries, con Cloud Run para aplicaciones serverless, con GKE para Kubernetes, y con Vertex AI para pipelines de datos es más fluida que cualquier cross-cloud. Si tu stack vive en Google Cloud, Cloud SQL es la opción obvia para PostgreSQL administrado.
¿Cuándo me generaría dudas? Si necesitás escalar compute sin interrumpir el servicio (Cloud SQL requiere restart para cambiar instancia), o si tu carga tiene picos muy variables donde un modelo de almacenamiento desacoplado tipo Aurora tendría ventajas. Para cargas write-heavy con requisitos estrictos de latencia, también habría que benchmarkar antes de asumir.
Algunas mejores prácticas concretas: elegí Enterprise Plus si el SLA de 99.99% sin excepción de mantenimiento importa para producción. Configurá HA desde el día uno si es una base de producción (agregarlo después no es complicado, pero el downtime de migración sí puede serlo). Usá read replicas para analytics y queries pesadas, no la primaria. Y revisá bien la retención de logs de PITR: 7 días en Enterprise puede quedarse corto si alguien descubre un problema una semana y media después.
Errores comunes al usar Cloud SQL
- Confundir ediciones al planificar features: Leer la documentación de Enterprise Plus y asumir que aplica a Enterprise lleva a sorpresas en producción. Cada feature tiene etiqueta de edición; verificala antes de diseñar la arquitectura.
- No configurar HA desde el inicio: Agregar HA a una instancia existente en producción implica un failover planificado (downtime breve). Hacerlo el día del lanzamiento con tráfico real no es lo ideal. Si es producción, arrancá con HA.
- Dimensionar el almacenamiento sin considerar el crecimiento de logs: Cloud SQL puede aumentar el almacenamiento automáticamente, pero eso no se puede reducir después. Empezar demasiado chico y dejar que crezca sin control lleva a discos grandes que pagan mucho aunque estén medio vacíos. Monitoreá y planificá desde el principio.
- Usar la IP pública sin Cloud SQL Auth Proxy: Exponer la instancia por IP pública sin el proxy es posible pero no recomendado. El Auth Proxy maneja la autenticación con IAM y el cifrado en tránsito sin tener que gestionar certificados SSL manualmente.
Preguntas Frecuentes
¿Qué es Google Cloud SQL para PostgreSQL?
Cloud SQL para PostgreSQL es el servicio de base de datos administrado de Google Cloud que ejecuta instancias PostgreSQL comunitarias en VMs gestionadas por Google. Incluye backups automatizados, recuperación punto en tiempo, alta disponibilidad opcional y read replicas, sin que el usuario tenga acceso al sistema operativo de la VM subyacente.
¿Cuál es la diferencia entre Cloud SQL Enterprise y Enterprise Plus?
Enterprise Plus usa hardware N2 más reciente, ofrece SLA de 99.99% que incluye ventanas de mantenimiento (Enterprise garantiza 99.95% con excepciones por mantenimiento), incluye Data Cache para reads, y retiene logs de PITR hasta 35 días vs 7 de Enterprise. En escrituras, Enterprise Plus puede duplicar la performance. Cuesta alrededor de un 20-30% más. Tema relacionado: en la estrategia de Google.
¿Cuánto tiempo tarda el failover en Cloud SQL?
El failover automático en una configuración de alta disponibilidad regional tarda alrededor de 60 segundos. La aplicación no necesita cambiar su connection string porque el endpoint permanece igual; solo necesita manejar la reconexión después del failover.
¿Cloud SQL tiene recuperación punto en tiempo (PITR)?
Sí. Cloud SQL soporta PITR con logs de transacciones. En Enterprise, la retención máxima es de 7 días; en Enterprise Plus, hasta 35 días. El RPO típico es de 5 minutos o menos, permitiendo restaurar la base a cualquier momento dentro del rango de retención.
¿Es Cloud SQL más barato que AWS RDS?
Depende del uso. Cloud SQL no cobra por transferencia de datos entre servicios dentro de GCP, lo que puede representar un ahorro significativo en cargas con alto volumen de egress. RDS puede resultar más económico en instancias de menor tamaño o con configuraciones específicas de Multi-AZ. La comparativa real requiere calcular con la carga concreta de cada proyecto.
Conclusión
El análisis de Christophe Pettus sobre Cloud SQL para PostgreSQL lo describe como un retorno a los fundamentos después de la arquitectura más experimental de Aurora. Eso es exacto, y no es necesariamente un problema. Una arquitectura predecible con comportamiento estándar de PostgreSQL es lo que muchos equipos necesitan.
Lo que sí requiere atención es la distinción entre ediciones. Enterprise Plus no es simplemente “más caro y más rápido”; tiene diferencias arquitectónicas en caché, mantenimiento y retención de logs que cambian decisiones de diseño. Si estás evaluando Cloud SQL para producción, definí primero qué SLA necesitás y qué ventana de PITR es aceptable para tu negocio. Eso solo ya determina qué edición usar.
Para equipos que ya viven en Google Cloud, Cloud SQL es la opción más integrada y con mejor ecuación en costos de egress. Para los que están evaluando clouds, la comparativa con RDS no tiene un ganador universal: el ecosistema donde corre el resto de tu aplicación es el factor determinante.
