PostgreSQL a Google Sheets: 4 métodos que funcionan

Llevar datos de PostgreSQL a Google Sheets se reduce a cuatro enfoques: exportación manual en CSV, Apps Script con JDBC, un conector ETL de terceros, o consultar Postgres directamente a través de DuckDB. Si necesitas los datos una sola vez, el CSV funciona. Si los necesitas cada semana -o tu equipo de análisis te pide constantemente "actualiza las cifras"- necesitas una de las otras tres opciones.

La mayoría de los equipos arranca con exportaciones en CSV y ahí se queda más tiempo del que debería. Hasta que alguien pregunta por qué los ingresos del deck para el board no coinciden con los del sistema, y de repente todos quieren una solución de verdad.

Por qué las exportaciones manuales en CSV terminan fallando

El flujo de exportar-y-pegar no es solo tedioso - es activamente riesgoso. Estás creando una copia manual de los datos en un momento específico y depositando esa instantánea estática en un lugar donde la gente la trata como si fuera información en tiempo real.

Según una encuesta de 2023 de Fivetran, el 67% de los analistas de datos dedica más de 4 horas semanales a tareas de movimiento manual de datos que podrían automatizarse. El dato cubre todas las herramientas, pero la sincronización entre hojas de cálculo y bases de datos aparece sistemáticamente entre las primeras causas.

Para un equipo de finanzas con ciclos de reporte semanales, una exportación desactualizada de Postgres implica cifras de P&L que pueden llevar días o semanas de rezago respecto a las transacciones reales. El problema no es incompetencia técnica -es que el camino más fácil (bajar CSV, pegar en Sheets) no escala más allá de "una vez".

Los 4 enfoques comparados

La elección correcta depende de si quieres escribir código, pagar por infraestructura, o simplemente ejecutar la consulta cuando la necesitas.

Apps Script + JDBC: la ruta gratuita, pero con costo en tiempo

Google Apps Script soporta conexiones JDBC directamente a PostgreSQL. Escribes una función que abre la conexión, ejecuta la consulta y escribe los resultados en un rango nombrado. Los triggers automáticos se encargan del calendario de actualización.

Esta es la implementación mínima viable:

function syncFromPostgres() {
  const conn = Jdbc.getConnection(
    'jdbc:postgresql://tu-host:5432/tu_db',
    'usuario',
    'contraseña'
  );
  const stmt = conn.prepareStatement(
    'SELECT fecha, ingresos, cogs, margen_bruto FROM finanzas.p_y_g WHERE fecha >= CURRENT_DATE - 90'
  );
  const results = stmt.executeQuery();
  const sheet = SpreadsheetApp.getActiveSpreadsheet().getSheetByName('P&G');
  let row = 2;
  while (results.next()) {
    sheet.getRange(row, 1, 1, 4).setValues([[
      results.getString(1),
      results.getFloat(2),
      results.getFloat(3),
      results.getFloat(4)
    ]]);
    row++;
  }
  results.close();
  conn.close();
}

Funciona, pero tiene limitaciones reales. El soporte JDBC de Google requiere que tu instancia de PostgreSQL sea públicamente accesible o que esté en lista blanca contra los rangos de IP de Google - una concesión de seguridad que muchos equipos no están dispuestos a hacer. A marzo de 2026, Google no publica una lista estable de direcciones IP de Apps Script para allowlisting, lo que convierte la configuración del firewall en un ejercicio de adivinanza.

El timeout de ejecución de Apps Script es de 6 minutos para cuentas de consumo y 30 minutos para Workspace. Si tu consulta devuelve más de unos pocos miles de filas, llegarás al límite antes de terminar.

Conectores ETL: ideales para algunos equipos, exceso para otros

Herramientas como Fivetran, Airbyte y Stitch sincronizan tus tablas de Postgres con Google Sheets (o más frecuentemente con BigQuery, que luego conectas a Sheets). La configuración es genuinamente sencilla: defines el origen, autentificas el destino y programas la sincronización.

La contrapartida es el costo y el nivel de abstracción. El plan base de Fivetran parte desde alrededor de $100/mes y cobra por filas activas al mes. El nivel cloud de Airbyte arranca en $3 por millón de registros sincronizados. Para un equipo que necesita sincronizar 3 tablas con frecuencia diaria, probablemente vale la pena. Para un analista que quiere ejecutar consultas ad hoc contra una instancia de Postgres en producción, es desproporcionado.

El problema mayor: los conectores ETL replican tablas completas. No escribes SQL contra el origen -configuras qué tablas sincronizar y luego consultas el destino. Si quieres ejecutar un join personalizado entre 4 tablas con filtros específicos, esa lógica tiene que vivir en algún punto aguas abajo.

DuckDB: la opción que la mayoría de los analistas no ha probado

DuckDB incluye una extensión nativa de postgres que adjunta una base de datos PostgreSQL activa como fuente consultable. En lugar de replicar tablas completas, ejecutas SQL directamente contra tu instancia de Postgres y recibes los resultados en tu hoja de cálculo.

La configuración de la conexión luce así internamente:

ATTACH 'dbname=analytics user=readonly password=... host=db.internal port=5432'
  AS pg (TYPE postgres);

Una vez adjunta la base de datos, puedes ejecutar cualquier consulta, incluyendo joins entre múltiples tablas con la lógica exacta que tu modelo requiere. Aquí un ejemplo realista para FP&A: un reporte de P&L por centro de costo con filtros de periodo contable sobre cuatro tablas relacionadas.

SELECT
  date_trunc('month', t.fecha_contable)                               AS periodo,
  cc.nombre                                                           AS centro_costo,
  c.codigo                                                            AS cuenta,
  c.nombre                                                            AS descripcion_cuenta,
  SUM(CASE WHEN t.tipo = 'credito' THEN t.monto ELSE 0 END)          AS creditos,
  SUM(CASE WHEN t.tipo = 'debito'  THEN t.monto ELSE 0 END)          AS debitos,
  SUM(CASE WHEN t.tipo = 'credito' THEN t.monto ELSE -t.monto END)   AS saldo_neto
FROM contabilidad.transacciones t
JOIN contabilidad.cuentas       c  ON t.cuenta_id        = c.id
JOIN contabilidad.centros_costo cc ON t.centro_costo_id  = cc.id
JOIN contabilidad.periodos      p  ON t.fecha_contable BETWEEN p.fecha_inicio AND p.fecha_fin
WHERE p.ejercicio   = 2026
  AND p.trimestre  IN (1, 2)
  AND c.tipo       IN ('ingreso', 'costo', 'gasto')
GROUP BY 1, 2, 3, 4
ORDER BY 1, 2, c.codigo;

Los resultados llegan directamente a tu hoja. No estás copiando datos a un warehouse intermedio -estás consultando Postgres a través de la memoria de DuckDB y escribiendo el output en un rango. Este enfoque es fundamentalmente distinto al patrón ETL porque tu SQL se ejecuta de nuevo cada vez que lo corres, contra datos en vivo. El detalle técnico de cómo funciona esta arquitectura lo cubrimos en la guía de DuckDB para Google Sheets.

Lo que nadie te dice sobre las conexiones Postgres → Sheets

La conexión en sí es la parte fácil. La parte difícil es la gestión de credenciales.

Todos los enfoques excepto el CSV requieren que tus credenciales de Postgres vivan en algún lugar: en las propiedades del proyecto de Apps Script, en el vault cifrado de un conector de terceros, o en un sistema de gestión de secretos. El modelo de amenaza es diferente en cada caso.

Apps Script almacena las credenciales en las propiedades del script, visibles para cualquier persona con acceso de editor al proyecto - y eso suele ser más gente de la que imaginas. La documentación de Google Apps Script señala explícitamente que "las propiedades del script son compartidas entre todos los usuarios de un script", lo que significa que cualquier colaborador de tu hoja puede leer tu contraseña de base de datos si la guardas ahí.

Antes de elegir un método, confirma con tu equipo de IT:

• ¿Quién tendrá acceso de editor a la hoja o al script donde se guardan las credenciales?
• ¿La herramienta cifra las credenciales en reposo, o las almacena en texto plano?
• ¿El conector de terceros tiene certificación SOC 2 o equivalente?

Para entornos de producción, la práctica recomendada es crear un usuario de Postgres con permisos de solo lectura y acceso restringido a los esquemas estrictamente necesarios - independientemente del método que uses para mover los datos.

Cómo conectar PostgreSQL a Google Sheets paso a paso

1. Abre el panel lateral de ModelMonkey en Google Sheets
2. Ve a Fuentes de datos y selecciona Agregar conexión
3. Elige PostgreSQL como tipo de proveedor
4. Ingresa el host, puerto, nombre de base de datos y esquema
5. Proporciona las credenciales - se cifran y nunca se almacenan en texto plano
6. Haz clic en Probar conexión para verificar el acceso
7. Una vez conectado, escribe tu consulta SQL o descríbela en lenguaje natural: "Trae los últimos 90 días de pedidos agrupados por categoría de producto"

La consulta se ejecuta de nuevo cada vez que la corres, contra datos en vivo. No hay programación de sincronización que mantener ni tablas intermedias que gestionar.

Preguntas frecuentes

¿Puedo conectar PostgreSQL a Google Sheets sin escribir código?

Sí. Los conectores ETL como Fivetran o Airbyte tienen interfaces visuales que no requieren código: defines el origen, el destino y el horario de sincronización desde un formulario. La contrapartida es que no controlas el SQL -el conector replica tablas completas, no consultas personalizadas. Si necesitas queries con JOINs o lógica de negocio específica sin escribir código, la alternativa es describir la consulta en lenguaje natural dentro de una herramienta que la traduzca a SQL automáticamente antes de ejecutarla.

¿Cada cuánto se actualizan los datos con cada método?

Depende del método que elijas. Con exportación en CSV la actualización es estrictamente manual. Apps Script con triggers puede correr cada hora como mínimo, dependiendo de tu plan de Workspace. Los ETL como Fivetran ofrecen sincronización cada 5 minutos en planes de pago. DuckDB con extensión nativa de Postgres ejecuta la consulta en el momento exacto en que la corres, contra datos en vivo - no hay caché ni retraso de sincronización acumulado.

¿Es seguro almacenar credenciales de Postgres en Google Sheets?

Depende de cómo las almacenes. Si las escribes directamente en una celda de la hoja, cualquier persona con acceso al archivo puede verlas - eso no es aceptable para entornos de producción. Apps Script las guarda en propiedades del proyecto, pero esas propiedades son visibles para todos los editores del script. La práctica recomendada es usar un usuario de Postgres de solo lectura con acceso mínimo a los esquemas necesarios, y elegir una herramienta que gestione las credenciales a través de un sistema externo de secretos - como Google Cloud Secret Manager o HashiCorp Vault - en lugar de almacenarlas dentro de la hoja misma.