Comparação: PgArachne vs. PostgREST
| Funcionalidade | PgArachne (+ Funções Universais) | PostgREST |
|---|---|---|
| Velocidade de Configuração | Alta. Funções universais permitem CRUD instantâneo semelhante ao PostgREST. | Alta. Gera automaticamente endpoints para todas as tabelas. |
| Flexibilidade Lógica | Ilimitada. Capacidade de combinar CRUD universal com funções RPC específicas. | Limitada. A maior parte da lógica deve residir em filtros de URL ou Views do Banco de Dados. |
| Manuseio de Esquemas | Nativo. Acesso via schema.function. | Plano/Global. Requer a troca de perfis nos cabeçalhos HTTP para mudar esquemas. |
| Abstração | Opcional. Você pode expor dados diretamente (proxy) ou encapsulá-los com segurança. | Baixa. A API é essencialmente um espelho do esquema do banco de dados. |
| Pronto para IA e LLM | Extrema. JSON-RPC e capacidade de definir funções “Tool” especificamente para agentes de IA. | Média. A IA tem que lutar com a sintaxe estrita de parâmetros de URL. |
| Arquivos Estáticos | Sim. Serve HTML/JS/CSS diretamente de um único binário. | Não. Você deve configurar e gerenciar um Nginx externo à frente dele. |
| Tempo real (SSE) | Sim. Endpoint SSE integrado para PostgreSQL NOTIFY. | Não. Requer wiring dedicado (LISTEN/NOTIFY + serviço separado). |
| Suporte Multi-Banco de Dados | Em todo o servidor (N:1). Uma única instância do PgArachne conecta-se ao servidor (IP:Porta) e pode servir todos os bancos de dados hospedados lá. | Por Banco de Dados (1:1). Uma instância está vinculada a um banco de dados específico. Servir vários bancos de dados requer a execução de várias instâncias em portas diferentes. |
| Autenticação | JWT e Chaves de API. Suporta nativamente ambos os mundos. | Principalmente JWT. |
| Rate limiting | Sim. Limite de login integrado (configurável). | Não. Requer proxy ou middleware externo. |
Por que o “PgArachne Híbrido” é o Vencedor?
Graças às Funções Universais (agindo como um emulador), você obtém o melhor dos dois mundos:
- Fase de Inicialização (MVP): Implante o PgArachne com algumas funções de proxy (como
as em
universal_table_access.sql) e em minutos você tem uma API funcional para todas as tabelas. Nesta fase, ele se comporta exatamente como o PostgREST. - Fase de Produção: À medida que a aplicação cresce, comece a escrever funções
dedicadas para operações sensíveis (ex:
process_payment). Isso aumenta a segurança e o desempenho sem alterar a pilha de tecnologia subjacente. - Frontend e IA: Ao mesmo tempo, sua aplicação roda na mesma porta que a API (graças ao serviço de arquivos estáticos), e agentes de IA podem chamar suas funções diretamente via JSON-RPC.
Nota: As “Funções Universais” são um conjunto de funções PL/pgSQL padrão que você pode adicionar ao seu banco de dados para habilitar operações genéricas de Leitura, Criação, Atualização e Exclusão em qualquer tabela.