Você sabia que o GeoServer pode armazenar toda a sua configuração (workspaces, stores, layers, styles) em um banco de dados PostgreSQL, em vez de gravar arquivos XML no diretório data_dir?

Isso é possível com dois módulos da comunidade: JDBCConfig e JDBCStore. Apesar de frequentemente usados juntos, eles têm funções diferentes e complementares.

🧩 1. O que é o JDBCConfig

O JDBCConfig é um módulo que permite ao GeoServer salvar toda a configuração do catálogo(metadados) dentro de um banco relacional, como o PostgreSQL.

Por padrão, o GeoServer armazena sua configuração em diversos arquivos XML dentro do diretório data_dir — um para cada workspace, store, camada e estilo. Com o módulo JDBCConfig, essas informações deixam de ser gravadas nesses arquivos e passam a ser persistidas diretamente em tabelas no banco de dados, substituindo por completo o backend de configuração baseado em arquivos.

1.1 O que ele armazena

  • Workspaces
  • DataStores (referências às fontes de dados)
  • Layers
  • Styles (metadados, não o conteúdo do arquivo em si)
  • Configurações globais e de serviços (WMS, WFS, etc.)

1.2 Vantagens

  • Melhor escalabilidade: evita o gargalo de leitura/escrita em centenas de XMLs.
  • Mais segurança em cluster: todas as instâncias compartilham o mesmo catálogo.
  • Gerenciamento centralizado: fácil backup, versionamento e replicação via banco.

1.3 Quando usar

  • Ambientes em cluster (várias instâncias do GeoServer).
  • Ambientes com muitas camadas e workspaces (centenas ou milhares).
  • Pode ser usado mesmo em um único servidor, apenas para reduzir I/O de disco e facilitar

🗂️ 2. O que é o JDBCStore

O JDBCStore é outro módulo comunitário que complementa o JDBCConfig. Ele permite armazenar os arquivos reais do data_dir (como estilos .sld, imagens, legendas e uploads) dentro do banco de dados, em vez de no sistema de arquivos.

Diferente do JDBCConfig, que salva metadados e estrutura do catálogo, o JDBCStore salva conteúdo binário (arquivos, blobs).

2.1 O que ele armazena

  • Arquivos de estilos (SLD, CSS)
  • Imagens usadas em símbolos e legendas
  • Arquivos de uploads feitos via REST ou UI
  • Qualquer outro recurso armazenado dentro de data_dir

2.2 Vantagens

  • Evita dependência de compartilhamento via NFS em clusters.
  • Centraliza todos os recursos no banco, junto com o catálogo.
  • Facilita backup e replicação, basta copiar o banco.

2.3 Quando usar

  • Com JDBCConfig, em ambiente clusterizado é ideal.
  • Sem JDBCConfig, se você quiser apenas armazenar os arquivos no banco e manter a configuração ainda em XML.
  • Útil também em servidores únicos, se você quiser facilitar deploys e migrações (sem precisar sincronizar pastas de estilos entre máquinas).

🔗 3. Relação e diferenças entre JDBCConfig e JDBCStore

Embora os dois módulos sejam frequentemente mencionados juntos, eles têm propósitos distintos dentro do GeoServer.

O JDBCConfig é responsável por armazenar as configurações do catálogo, ou seja, toda a estrutura de metadados que descreve o funcionamento do GeoServer, os workspaces, as conexões com bancos de dados, as camadas e os estilos associados. Ele substitui o modelo tradicional baseado em arquivos XML, gravando essas informações diretamente em tabelas no banco de dados.

Já o JDBCStore atua em outro nível: ele armazena o conteúdo físico dos arquivos que normalmente ficam no data_dir. Isso inclui estilos (.sld, .css), imagens, legendas e qualquer outro arquivo binário usado pelo GeoServer. Em vez de deixar esses recursos no sistema de arquivos, o JDBCStore os grava como blobs dentro do banco.

Os dois módulos podem funcionar independentemente. Você pode usar apenas o JDBCConfig, mantendo os arquivos (como SLDs) ainda no disco ou apenas o JDBCStore, guardando os arquivos no banco, mas deixando o catálogo em XML.

No entanto, o uso conjunto dos dois traz o máximo de benefícios: a configuração e os recursos do GeoServer passam a ser totalmente centralizados e sincronizados no banco de dados, eliminando a necessidade de um diretório compartilhado via NFS.

Resumindo:

  • O JDBCConfig guarda o “quem é quem” (a estrutura de configuração).
  • O JDBCStore guarda o “o que é” (os arquivos e recursos reais).
  • Usados juntos, eliminam completamente a necessidade de um data_dir compartilhado, tornando o GeoServer mais robusto e escalável em ambientes distribuídos.

⚙️ 4. Como instalar o JDBCConfig e o JDBCStore no GeoServer 2.28.0

4.1 Baixar os módulos

Acesse a página de Community Modules da sua versão: https://geoserver.org/release/2.28.x/

Baixe os arquivos:

geoserver-2.28.x-jdbcconfig-plugin.zip
geoserver-2.28.x-jdbcstore-plugin.zip

Extraia os .jar e copie para:

GEOSERVER_HOME/WEB-INF/lib/

4.2 Criar o banco no PostgreSQL

Crie um novo banco vazio, por exemplo:

CREATE DATABASE geoserver_catalog;
CREATE USER geoserver_user WITH PASSWORD 'senha_segura';
GRANT ALL PRIVILEGES ON DATABASE geoserver_catalog TO geoserver_user;

4.3 Configurar o JDBCConfig

Após o primeiro restart do GeoServer com o módulo instalado, será criada a pasta:

data_dir/jdbcconfig/

Dentro dela há um arquivo de exemplo jdbcconfig.properties.postgres. Edite-o e configure conforme abaixo:

enabled=true
initdb=true
import=true
...
username=geoserver_user
password=senha_segura
jdbcUrl=jdbc:postgresql://localhost:5432/geoserver_catalog

Salve o arquivo como jdbcconfig.properties, reinicie o GeoServer e observe no log, se tudo estiver certo, ele criará as tabelas automaticamente e importará sua configuração XML atual para o banco.

4.4 Configurar o JDBCStore

Após instalar o módulo jdbcstore, um diretório semelhante será criado:

data_dir/jdbcstore/

Edite o arquivo jdbcstore.properties (também há um .postgres de exemplo):

enabled=true
initdb=true
...
username=geoserver_user
password=senha_segura
jdbcUrl=jdbc:postgresql://localhost:5432/geoserver_catalog

Reinicie o GeoServer novamente.

🧠 5. Conclusão

O uso do JDBCConfig e do JDBCStore traz uma série de benefícios, especialmente em ambientes de alta disponibilidade ou clusterizados.

Eles permitem que toda a configuração e os recursos do GeoServer sejam armazenados de forma transacional, centralizada e sincronizada dentro de um banco de dados relacional.

Mas mesmo em ambientes sem cluster, esses módulos podem ser vantajosos para quem busca:

  • Simplificar backups e migrações (basta exportar o banco);
  • Reduzir I/O de disco em instalações muito grandes;
  • Facilitar o versionamento da configuração.

E você leitor, conhecia esses módulos do GeoServer? O que achou? Deixe seu comentário, vou gostar de saber sua opinião.