PostGIS alojado: ¿qué servicio elegir?

Qué se espera de una base PostGIS alojada

PostgreSQL es un motor de base de datos libre; PostGIS es su extensión espacial, también libre, que añade los tipos geometría y geografía, los índices espaciales y cientos de funciones de análisis. Una base PostGIS alojada es esa pareja instalada, actualizada y supervisada por un proveedor, que usted utiliza a distancia.

Para el trabajo SIG, la necesidad es concreta: cargar capas desde QGIS, editarlas entre varios, publicarlas en un visor cartográfico o un servidor OGC y no perder nunca datos. La verdadera pregunta no es solo dónde encontrar un PostgreSQL en línea, sino qué servicio simplifica ese flujo de trabajo en el día a día.

Los servicios en la nube generalistas

Los grandes servicios de PostgreSQL gestionado ofrecen todos PostGIS, que usted activa con un comando SQL. Son productos excelentes, pensados ante todo para desarrolladores de aplicaciones, con opciones avanzadas: réplicas, escalado automático, ramas de datos.

Disponibilidad de PostGIS verificada el 09/11/2026 en la documentación de Amazon RDS, en la página de extensiones de Supabase y en la documentación de Neon. Las versiones de PostGIS varían según la versión de PostgreSQL elegida. Los precios de estos servicios dependen de muchos parámetros y no se recogen aquí: consulte sus páginas oficiales.

Cinco criterios para elegir un PostGIS alojado

• PostGIS disponible y actualizado. Compruebe la versión de PostGIS ofrecida y cómo activarla. En un servicio generalista, la extensión la crea usted; en una base pensada para SIG, ya está instalada.
• Conexión desde QGIS. QGIS se conecta directamente a PostgreSQL. Hace falta una dirección accesible desde su equipo, credenciales fáciles de copiar y ninguna red privada que configurar.
• Conexión cifrada (SSL). Sus datos circulan por Internet: la conexión debe ir cifrada, sin manejos complicados de certificados en QGIS.
• Tamaño y desbordamiento. ¿Qué ocurre cuando la base está llena? Recibir un aviso a tiempo y no perder nada importa más que un gran volumen teórico.
• Precio claro por GB. Un SIG crece con sus datos. Un precio por GB y por mes se prevé con facilidad; una facturación por tiempo de cálculo, operaciones de E/S y transferencia exige una estimación más fina.

Añada a estos cinco criterios una pregunta práctica: ¿quién le responde cuando falla una conexión? En un servicio generalista, el soporte cubre PostgreSQL en general; un error de proyección, un índice espacial ausente o una capa que no se muestra en QGIS quedan a su cargo. Un alojamiento orientado al SIG conoce estas situaciones y habla el mismo idioma que sus técnicos SIG.

Una base pensada para SIG: el enfoque de LizPack

LizPack, infraestructura geoespacial de código abierto, no ha escrito PostgreSQL ni PostGIS: los aloja y los mantiene. Las bases PostgreSQL/PostGIS dedicadas se entregan con PostgreSQL 17 y PostGIS 3.5, y con las extensiones hstore, uuid-ossp y pg_trgm ya instaladas.

• Cada base tiene sus credenciales y una conexión SSL, utilizable desde QGIS Desktop, pgAdmin, DBeaver o sus scripts.
• Usted elige el tamaño al crearla, de 1 a 10 GB; la facturación sigue ese volumen, por GB y por mes.
• Un correo le avisa al llegar al 60 % de ocupación, y luego al 75, 80, 90 y 95 %.
• Por encima de la cuota, dispone de 24 horas para liberar espacio; después la base se detiene, sin que se borre ningún dato.
• Una base conectada a una instancia LizPack Map sirve sus capas en el mapa, editables en línea; también se conecta a GeoServer Cloud y recibe los levantamientos de LizPack Field.

Los planes Basic y Pro ya incluyen un almacenamiento PostgreSQL/PostGIS vinculado a la instancia LizPack Map, accesible directamente desde QGIS a partir del plan Pro. Las bases dedicadas son bases adicionales, dimensionadas de forma independiente. El precio vigente por GB aparece en la página de precios.

Poner en marcha una base PostGIS alojada

Sea cual sea el servicio elegido, la puesta en marcha de un PostGIS alojado sigue el mismo camino. Aquí lo tiene con una base de LizPack, indicando lo que cambia en otros servicios.

1. Crear la base desde el panel eligiendo su tamaño, entre 1 y 10 GB. En un servicio generalista, además hay que elegir una región, un tipo de máquina y reglas de red.
2. Copiar el host, el puerto y las credenciales. En un servicio generalista, compruebe que la dirección de su equipo está autorizada a conectarse.
3. Añadir una conexión PostgreSQL en QGIS con esos datos, en modo SSL, y guardarla para todo el equipo.
4. Importar sus capas desde QGIS o con la herramienta ogr2ogr de GDAL. En un servicio generalista, cree antes la extensión PostGIS en la base.
5. Conectar la base a su instancia LizPack Map para servir sus capas en el mapa, editables en línea.

Para dejar un servicio o cambiar de proveedor, bastan las herramientas estándar de PostgreSQL: pg_dump exporta la base y pg_restore la carga en otro lugar. Es la ventaja de un formato abierto: su base no está atada a ningún proveedor y puede hacer una prueba sin miedo a quedarse encerrado. Solo compruebe que la versión de PostGIS de destino sea igual o superior a la de origen.

Los errores de conexión más frecuentes desde QGIS

La mayoría de los fallos de conexión a una base PostGIS alojada tienen causas conocidas. Antes de abrir una incidencia, repase esta lista: resuelve la gran mayoría de los casos, sea cual sea el proveedor.

• Tiempo de espera agotado (timeout). El equipo no llega al servidor. En un servicio generalista, la dirección IP de su equipo a menudo no está autorizada en las reglas de red. En la oficina, un cortafuegos también puede bloquear el puerto de PostgreSQL: pregunte a su servicio informático si está abierto en salida.
• Fallo de autenticación por contraseña. El usuario o la contraseña son incorrectos, a menudo por un espacio copiado de más o un carácter especial mal pegado. Cópielos de nuevo desde el origen en lugar de volver a escribirlos.
• La base no existe. El nombre de la base no es el del usuario. Revise el campo base de datos de la conexión: debe contener el nombre exacto facilitado por el proveedor.
• Error SSL. El servidor exige una conexión cifrada y el cliente no la pide, o al revés. En QGIS, el modo SSL se ajusta en la ventana de conexión; el modo require cifra la conexión sin verificar el certificado, mientras que verify-ca y verify-full verifican además la identidad del servidor, pero necesitan su certificado de autoridad.
• Capas vacías o ausentes. La conexión funciona pero no aparece ninguna capa: la tabla no tiene columna geométrica registrada, o el usuario no tiene permiso de lectura sobre el esquema. Marque también la opción que muestra las tablas sin geometría si busca una tabla solo de atributos.

Guarde la configuración que funciona: host, puerto, nombre de la base, modo SSL. El día que un compañero no consiga conectarse, comparar su conexión con la suya llevará un minuto.

Sistema de coordenadas e índices espaciales: dos ajustes que marcan la velocidad

Una base PostGIS alojada lenta rara vez es un problema del servidor. En la mayoría de los casos, la causa es un sistema de coordenadas mal declarado o un índice espacial ausente. Ambos se corrigen en pocos minutos.

• Declare el SRID correcto. Cada columna geométrica lleva un código de sistema de coordenadas (SRID), por ejemplo 4326 para las coordenadas geográficas WGS 84. Una columna declarada con un SRID erróneo se muestra en el lugar equivocado, u obliga a QGIS a reproyectar cada entidad al vuelo. Las funciones Find_SRID y UpdateGeometrySRID de PostGIS permiten comprobar y corregir la declaración.
• Almacene en una proyección adaptada a sus mediciones. Para calcular superficies y distancias en metros sobre un territorio, una proyección métrica local evita conversiones. Mantenga el mismo sistema en las tablas que cruza a menudo: una unión espacial entre dos SRID distintos obliga a PostGIS a transformar las geometrías.
• Cree un índice espacial. Un índice GiST sobre la columna geométrica (CREATE INDEX ... USING GIST) permite a PostGIS leer solo las entidades de la zona mostrada. Sin él, cada desplazamiento del mapa recorre toda la tabla. QGIS crea uno por defecto al importar, pero las tablas cargadas por script o con ogr2ogr y opciones personalizadas a veces carecen de él.
• Actualice las estadísticas. Tras una importación grande, el comando ANALYZE informa al planificador de consultas sobre el contenido de la tabla. Así elegirá usar el índice en lugar de un recorrido completo.

Estos ajustes pesan todavía más cuando la base alimenta un mapa en línea: cada visitante lanza consultas, y un índice ausente se paga en cada visualización.

Proteger las credenciales de la base en sus proyectos QGIS

Por defecto, QGIS puede guardar el usuario y la contraseña de una conexión PostgreSQL en claro dentro del archivo del proyecto. Es práctico, pero cualquier archivo .qgs o .qgz enviado por correo o dejado en un disco compartido lleva entonces las llaves de su base.

• Use el gestor de autenticación de QGIS. Guarda las credenciales en una base local cifrada con una contraseña maestra. El proyecto solo contiene una referencia a esa configuración, no la contraseña.
• O un archivo de servicio PostgreSQL. El archivo pg_service.conf asocia un nombre de servicio al host, al puerto y a la base. El proyecto hace referencia al servicio; cada equipo conserva sus propios parámetros.
• Cree cuentas distintas según el uso. Una cuenta de solo lectura para consultar, una cuenta de escritura para los editores. Si una credencial se filtra, el daño queda limitado.
• Cambie la contraseña cuando un colaborador se vaya, y compruebe que ningún proyecto compartido contiene la anterior en claro.

Para un proyecto publicado en la web, la cuestión es distinta: es el servidor cartográfico el que se conecta a la base, con sus propias credenciales, y los visitantes nunca acceden a ella directamente. En una instancia LizPack Map, la conexión entre Lizmap, QGIS Server y PostGIS se entrega ya configurada.

Respaldar y dimensionar un PostGIS alojado

Un proveedor protege su infraestructura, pero sus errores siguen siendo suyos: una tabla borrada por descuido o una actualización SQL mal dirigida solo se recuperan con una copia. Conserve por tanto sus propias exportaciones, además de las protecciones del proveedor.

1. Exportar la base en formato personalizado con pg_dump (opción -Fc): el archivo va comprimido y puede restaurarse tabla por tabla si hace falta.
2. Conservar varias copias fechadas, al menos una fuera de su equipo de trabajo.
3. Restaurar de vez en cuando una copia en una base de prueba con pg_restore, para comprobar que está completa.
4. Anotar la versión de PostgreSQL y de PostGIS de cada exportación: una restauración se hace hacia una versión igual o más reciente.

Para el tamaño, parta del volumen real de sus datos, no del de los archivos de origen: una capa importada en PostGIS, con sus índices, suele ocupar un volumen distinto al de su Shapefile o su GeoPackage. Importe una muestra representativa, mida el espacio ocupado con la función pg_database_size y extrapole con un margen para el crecimiento. Los ráster voluminosos suelen estar mejor como archivos servidos por un servidor cartográfico que dentro de la propia base.

En LizPack, el tamaño de una base dedicada se elige entre 1 y 10 GB al crearla, y las alertas de ocupación le dejan tiempo para reaccionar antes de llegar al límite.

Cuándo preferir una u otra opción

Un servicio generalista conviene más si su base sirve ante todo a una aplicación de negocio, si necesita varios cientos de gigabytes o réplicas de lectura, o si su organización ya trabaja con un proveedor de nube. Gana en potencia lo que invierte en configuración y en seguimiento de la factura.

Una base pensada para SIG conviene más si sus usuarios trabajan en QGIS, si los volúmenes se quedan en unos pocos gigabytes y si la base debe alimentar un mapa en línea. Para comparar con una instalación en su propio servidor, lea alojar Lizmap o instalarlo uno mismo; para el presupuesto global, cuánto cuesta un SIG web de código abierto; y para entender nuestro papel, qué hace LizPack.

Preguntas frecuentes