PostGIS alojado: que serviço escolher?

O que se espera de uma base PostGIS alojada

O PostgreSQL é um motor de base de dados livre; o PostGIS é a sua extensão espacial, também livre, que acrescenta os tipos geometria e geografia, os índices espaciais e centenas de funções de análise. Uma base PostGIS alojada é este par instalado, atualizado e monitorizado por um prestador, que utiliza à distância.

Para trabalho SIG, a necessidade é concreta: carregar camadas a partir do QGIS, editá-las em equipa, publicá-las num portal cartográfico ou num servidor OGC e nunca perder dados. A verdadeira questão não é apenas onde encontrar um PostgreSQL online, mas que serviço torna esse fluxo de trabalho simples no dia a dia.

Os serviços de nuvem generalistas

Os grandes serviços de PostgreSQL gerido oferecem todos o PostGIS, que ativa com um comando SQL. São produtos excelentes, pensados sobretudo para programadores de aplicações, com opções avançadas: réplicas, escalamento automático, ramos de dados.

Disponibilidade do PostGIS verificada a 09/11/2026 na documentação do Amazon RDS, na página de extensões do Supabase e na documentação do Neon. As versões do PostGIS variam com a versão do PostgreSQL escolhida. Os preços destes serviços dependem de muitos parâmetros e não são aqui reproduzidos: consulte as suas páginas oficiais.

Cinco critérios para escolher um PostGIS alojado

• PostGIS disponível e atualizado. Verifique a versão do PostGIS proposta e a forma de o ativar. Num serviço generalista, é o utilizador que cria a extensão; numa base pensada para SIG, já lá está.
• Ligação a partir do QGIS. O QGIS liga-se diretamente ao PostgreSQL. É preciso um endereço acessível a partir do seu posto, credenciais fáceis de copiar e nenhuma rede privada para configurar.
• Ligação cifrada (SSL). Os seus dados circulam pela Internet: a ligação tem de ser cifrada, sem manipulação complicada de certificados no QGIS.
• Tamanho e excesso. O que acontece quando a base está cheia? Ser avisado cedo e não perder nada conta mais do que um grande volume teórico.
• Preço claro por GB. Um SIG cresce com os seus dados. Um preço por GB e por mês prevê-se facilmente; uma faturação por tempo de cálculo, operações de E/S e transferência exige uma estimativa mais fina.

Acrescente a estes cinco critérios uma questão prática: quem lhe responde quando uma ligação falha? Num serviço generalista, o suporte abrange o PostgreSQL em geral; um erro de projeção, um índice espacial em falta ou uma camada que não aparece no QGIS ficam a seu cargo. Um alojamento orientado para SIG conhece estas situações e fala a mesma linguagem dos seus técnicos de SIG.

Uma base pensada para SIG: a abordagem LizPack

A LizPack, infraestrutura geoespacial de código aberto, não escreveu o PostgreSQL nem o PostGIS: aloja-os e mantém-nos. As bases PostgreSQL/PostGIS dedicadas são entregues com PostgreSQL 17 e PostGIS 3.5, e com as extensões hstore, uuid-ossp e pg_trgm já instaladas.

• Cada base tem as suas credenciais e uma ligação SSL, utilizável a partir do QGIS Desktop, do pgAdmin, do DBeaver ou dos seus scripts.
• Escolhe o tamanho na criação, de 1 a 10 GB; a faturação acompanha esse volume, por GB e por mês.
• Um correio eletrónico avisa-o aos 60 % de ocupação, e depois aos 75, 80, 90 e 95 %.
• Acima da quota, tem 24 horas para libertar espaço; depois a base é parada, sem que nenhum dado seja apagado.
• Uma base ligada a uma instância LizPack Map serve as suas camadas no mapa, editáveis online; liga-se também ao GeoServer Cloud e recebe os levantamentos do LizPack Field.

Os planos Basic e Pro já incluem um armazenamento PostgreSQL/PostGIS associado à instância LizPack Map, acessível diretamente a partir do QGIS desde o plano Pro. As bases dedicadas são bases adicionais, dimensionadas de forma independente. O preço atual por GB é apresentado na página de preços.

Pôr a funcionar uma base PostGIS alojada

Seja qual for o serviço escolhido, pôr a funcionar um PostGIS alojado segue o mesmo caminho. Eis o percurso com uma base LizPack, indicando o que muda noutros serviços.

1. Criar a base no painel escolhendo o tamanho, entre 1 e 10 GB. Num serviço generalista, é ainda preciso escolher uma região, um tipo de máquina e regras de rede.
2. Copiar o anfitrião, a porta e as credenciais. Num serviço generalista, verifique se o endereço do seu posto está autorizado a ligar-se.
3. Adicionar uma ligação PostgreSQL no QGIS com esses dados, em modo SSL, e guardá-la para toda a equipa.
4. Importar as suas camadas a partir do QGIS ou com a ferramenta ogr2ogr do GDAL. Num serviço generalista, crie antes a extensão PostGIS na base.
5. Ligar a base à sua instância LizPack Map para servir as camadas no mapa, editáveis online.

Para deixar um serviço ou mudar de fornecedor, bastam as ferramentas normais do PostgreSQL: o pg_dump exporta a base e o pg_restore carrega-a noutro lado. É a vantagem de um formato aberto: a sua base não fica presa a nenhum fornecedor, e pode fazer um teste sem receio de ficar dependente. Verifique apenas que a versão do PostGIS de destino é igual ou superior à de origem.

Os erros de ligação mais frequentes a partir do QGIS

A maior parte das falhas de ligação a uma base PostGIS alojada tem causas conhecidas. Antes de abrir um pedido de suporte, percorra esta lista: resolve a grande maioria dos casos, seja qual for o fornecedor.

• Tempo de espera esgotado (timeout). O posto não chega ao servidor. Num serviço generalista, o endereço IP do seu posto muitas vezes não está autorizado nas regras de rede. No escritório, uma firewall pode também bloquear a porta do PostgreSQL: pergunte ao seu serviço de informática se está aberta em saída.
• Falha de autenticação por palavra-passe. O utilizador ou a palavra-passe estão errados, muitas vezes por causa de um espaço copiado a mais ou de um carácter especial mal colado. Copie-os de novo a partir da origem em vez de os escrever outra vez.
• A base não existe. O nome da base não é o do utilizador. Verifique o campo base de dados da ligação: tem de conter o nome exato fornecido pelo alojamento.
• Erro SSL. O servidor exige uma ligação cifrada e o cliente não a pede, ou o contrário. No QGIS, o modo SSL define-se na janela de ligação; o modo require cifra a ligação sem verificar o certificado, enquanto os modos verify-ca e verify-full verificam também a identidade do servidor, mas precisam do respetivo certificado de autoridade.
• Camadas vazias ou ausentes. A ligação funciona mas não aparece nenhuma camada: a tabela não tem coluna geométrica registada, ou o utilizador não tem permissão de leitura sobre o esquema. Assinale também a opção que lista as tabelas sem geometria se procura uma tabela só de atributos.

Guarde um registo da configuração que funciona: anfitrião, porta, nome da base, modo SSL. No dia em que um colega não conseguir ligar-se, comparar a ligação dele com a sua demora um minuto.

Sistema de coordenadas e índices espaciais: dois ajustes que fazem a velocidade

Uma base PostGIS alojada lenta raramente é um problema do servidor. Na maioria dos casos, a causa é um sistema de coordenadas mal declarado ou um índice espacial em falta. Ambos se resolvem em poucos minutos.

• Declare o SRID correto. Cada coluna geométrica tem um código de sistema de coordenadas (SRID), por exemplo 4326 para as coordenadas geográficas WGS 84. Uma coluna declarada com um SRID errado aparece no sítio errado, ou obriga o QGIS a reprojetar cada elemento em tempo real. As funções Find_SRID e UpdateGeometrySRID do PostGIS permitem verificar e corrigir a declaração.
• Guarde numa projeção adequada às suas medições. Para calcular áreas e distâncias em metros num território, uma projeção métrica local evita conversões. Mantenha o mesmo sistema nas tabelas que cruza com frequência: uma junção espacial entre dois SRID diferentes obriga o PostGIS a transformar as geometrias.
• Crie um índice espacial. Um índice GiST sobre a coluna geométrica (CREATE INDEX ... USING GIST) permite ao PostGIS ler apenas os elementos da zona apresentada. Sem ele, cada deslocação do mapa percorre a tabela inteira. O QGIS cria um por omissão ao importar, mas as tabelas carregadas por script ou pelo ogr2ogr com opções personalizadas às vezes não o têm.
• Atualize as estatísticas. Depois de uma importação grande, o comando ANALYZE informa o planeador de consultas sobre o conteúdo da tabela. Este passa então a usar o índice em vez de uma leitura completa.

Estes ajustes contam ainda mais quando a base alimenta um mapa online: cada visitante desencadeia consultas, e um índice em falta paga-se em cada visualização.

Proteger as credenciais da base nos seus projetos QGIS

Por omissão, o QGIS pode gravar o utilizador e a palavra-passe de uma ligação PostgreSQL em claro no ficheiro do projeto. É prático, mas qualquer ficheiro .qgs ou .qgz partilhado por correio eletrónico ou colocado num disco partilhado transporta então as chaves da sua base.

• Use o gestor de autenticação do QGIS. Guarda as credenciais numa base local cifrada com uma palavra-passe principal. O projeto passa a conter apenas uma referência a essa configuração, e não a palavra-passe.
• Ou um ficheiro de serviço PostgreSQL. O ficheiro pg_service.conf associa um nome de serviço ao anfitrião, à porta e à base. O projeto refere o serviço; cada posto guarda os seus próprios parâmetros.
• Crie contas distintas por utilização. Uma conta só de leitura para consulta, uma conta com escrita para os editores. Se uma credencial for divulgada, os danos ficam limitados.
• Mude a palavra-passe quando um colaborador sair, e verifique que nenhum projeto partilhado contém a antiga em claro.

Para um projeto publicado na web, a questão é outra: é o servidor cartográfico que se liga à base, com as suas próprias credenciais, e os visitantes nunca lhe acedem diretamente. Numa instância LizPack Map, a ligação entre o Lizmap, o QGIS Server e o PostGIS é entregue já configurada.

Fazer cópias e dimensionar um PostGIS alojado

Um alojamento protege a sua infraestrutura, mas os seus erros continuam a ser seus: uma tabela apagada por engano ou uma atualização SQL mal dirigida só se recuperam com uma cópia. Guarde por isso as suas próprias exportações, além das proteções do fornecedor.

1. Exportar a base em formato personalizado com o pg_dump (opção -Fc): o ficheiro fica comprimido e pode ser restaurado tabela a tabela, se necessário.
2. Guardar várias cópias datadas, pelo menos uma fora do seu posto de trabalho.
3. Restaurar de vez em quando uma cópia numa base de teste com o pg_restore, para verificar que está completa.
4. Anotar a versão do PostgreSQL e do PostGIS de cada exportação: um restauro faz-se para uma versão igual ou mais recente.

Para o tamanho, parta do volume real dos seus dados, e não do dos ficheiros de origem: uma camada importada no PostGIS, com os seus índices, ocupa muitas vezes um volume diferente do seu Shapefile ou GeoPackage. Importe uma amostra representativa, meça o espaço ocupado com a função pg_database_size e extrapole com uma margem para o crescimento. Os rasters volumosos ficam muitas vezes melhor como ficheiros servidos por um servidor cartográfico do que dentro da própria base.

Na LizPack, o tamanho de uma base dedicada escolhe-se entre 1 e 10 GB na criação, e os alertas de ocupação dão-lhe tempo para reagir antes de atingir o limite.

Quando preferir uma ou outra opção

Um serviço generalista convém mais se a sua base serve sobretudo uma aplicação de negócio, se precisa de várias centenas de gigabytes ou de réplicas de leitura, ou se a sua organização já está comprometida com um fornecedor de nuvem. Ganha em potência o que gasta em configuração e em acompanhamento da fatura.

Uma base pensada para SIG convém mais se os seus utilizadores trabalham no QGIS, se os volumes ficam por alguns gigabytes e se a base tem de alimentar um mapa online. Para comparar com uma instalação no seu próprio servidor, leia alojar o Lizmap ou instalá-lo por conta própria; para o orçamento global, quanto custa um SIG web open source; e para perceber o nosso papel, o que faz a LizPack.

Perguntas frequentes