Tipos de Dados Oracle vs PostgreSQL: Guia Completo para Migração de Banco de Dados
Tipos de Dados Oracle vs PostgreSQL é um dos pontos mais importantes de uma migração de banco de dados, porque diferenças na representação, precisão, armazenamento e comportamento dos dados podem afetar aplicações, consultas SQL, procedures, integrações e processos de carga. Em projetos de migração Oracle para PostgreSQL, o mapeamento correto dos tipos de dados deve ser realizado durante o assessment e validado antes da conversão definitiva do ambiente.
Embora Oracle Database e PostgreSQL ofereçam tipos de dados equivalentes ou funcionalmente próximos em diversas situações, não existe uma correspondência universal de um para um entre todos os tipos Oracle e PostgreSQL. Alguns tipos podem ser convertidos diretamente, enquanto outros exigem análise da aplicação, transformação de dados, alteração de DDL ou adaptação do código SQL.
Por que os tipos de dados são críticos na migração Oracle para PostgreSQL?
Uma migração de Oracle para PostgreSQL não consiste simplesmente em exportar tabelas e importar registros em outro banco de dados. O modelo de dados precisa ser analisado para garantir que os valores armazenados no ambiente PostgreSQL mantenham o significado, a precisão e o comportamento esperados pela aplicação.
Uma escolha inadequada de tipo pode provocar problemas como:
- perda de precisão numérica;
- alteração do comportamento de datas e horários;
- diferenças no tratamento de strings;
- problemas de compatibilidade com aplicações;
- erros em procedures e funções;
- alterações no resultado de consultas;
- problemas em índices;
- mudanças no consumo de armazenamento;
- falhas em integrações;
- necessidade de conversões adicionais durante a execução.
Por isso, o mapeamento dos tipos deve fazer parte do planejamento técnico da migração e não ser tratado apenas como uma etapa operacional de conversão das tabelas.
Oracle e PostgreSQL possuem tipos de dados equivalentes?
Em muitos casos, existe um tipo PostgreSQL que atende à mesma necessidade funcional de um tipo Oracle. Entretanto, equivalência funcional não significa necessariamente equivalência técnica absoluta.
Durante o processo de conversão, é necessário avaliar:
- faixa de valores permitida;
- precisão e escala;
- tamanho máximo;
- representação interna;
- semântica de data e hora;
- tratamento de NULL;
- conversões implícitas;
- comparações;
- ordenação;
- indexação;
- funções SQL utilizadas pela aplicação.
Um tipo que parece equivalente na definição da tabela pode apresentar comportamento diferente quando utilizado em cálculos, filtros, ordenações, joins, índices ou código procedural.
Comparativo dos principais tipos de dados Oracle vs PostgreSQL
| Oracle | PostgreSQL | Observação |
|---|---|---|
| NUMBER | numeric / decimal | Conversão comum para valores numéricos de precisão exata |
| INTEGER | integer | Tipo inteiro compatível em diversos cenários |
| VARCHAR2 | varchar / text | Deve ser analisado conforme tamanho e regras da aplicação |
| CHAR | char | Ambos representam strings de tamanho fixo |
| DATE | timestamp | Requer atenção ao comportamento de data e hora |
| TIMESTAMP | timestamp | Há diferenças de precisão e semântica que devem ser avaliadas |
| TIMESTAMP WITH TIME ZONE | timestamp with time zone | Mapeamento funcional próximo, mas o comportamento deve ser validado |
| CLOB | text | Normalmente utilizado para grandes volumes de texto |
| BLOB | bytea | Usado para armazenamento de dados binários |
| RAW | bytea | Conversão depende da utilização da coluna |
| LONG | text | Tipo legado que deve ser analisado durante a migração |
| LONG RAW | bytea | Tipo legado que normalmente exige tratamento específico |
| FLOAT | double precision / numeric | A escolha depende da precisão requerida |
| REAL | real | Tipo de ponto flutuante |
| BOOLEAN | boolean | Deve ser avaliado conforme versão e utilização no Oracle |
| RAW | bytea | Indicado para dados binários, conforme o uso original |
A tabela serve como referência inicial. O mapeamento definitivo deve considerar o uso real de cada coluna e não apenas o nome do tipo de dado.
NUMBER Oracle vs numeric PostgreSQL
O NUMBER é um dos tipos mais importantes em uma migração Oracle para PostgreSQL. Ele pode ser utilizado para valores inteiros, valores decimais e números de alta precisão.
No PostgreSQL, o tipo numeric ou decimal normalmente é utilizado quando a aplicação exige precisão exata.
Porém, uma conversão automática de NUMBER para numeric não deve eliminar a análise de precisão e escala.
NUMBER sem precisão e escala
Uma coluna Oracle definida simplesmente como NUMBER pode aceitar diferentes valores numéricos. Antes da conversão, é importante verificar os valores efetivamente armazenados e a forma como a aplicação utiliza a coluna.
NUMBER(p,s)
Quando Oracle utiliza uma definição como NUMBER(15,2), existe uma precisão e uma escala explicitamente estabelecidas.
O PostgreSQL oferece mecanismo equivalente por meio de numeric(15,2), permitindo preservar a precisão decimal esperada.
Impacto na aplicação
A escolha entre numeric, integer, bigint, real e double precision pode influenciar desempenho, armazenamento e comportamento matemático. Portanto, nem todo NUMBER deve obrigatoriamente ser convertido para numeric sem análise.
VARCHAR2 Oracle vs VARCHAR e TEXT PostgreSQL
O VARCHAR2 é amplamente utilizado em aplicações Oracle para armazenamento de informações textuais.
No PostgreSQL, os equivalentes mais comuns são varchar e text.
VARCHAR2 para VARCHAR
Quando a definição Oracle possui limite explícito, como VARCHAR2(100), o PostgreSQL pode utilizar varchar(100), preservando a restrição de tamanho definida pelo modelo.
VARCHAR2 para TEXT
Em determinadas arquiteturas, a coluna pode ser convertida para text quando a limitação explícita de tamanho não possui importância funcional.
Entretanto, essa decisão deve ser tomada com base nas regras da aplicação, validações existentes e requisitos do modelo de dados.
Impacto de caracteres e codificação
Além do tamanho da coluna, é necessário analisar encoding, caracteres especiais, acentuação e regras de comparação utilizadas pela aplicação.
Essa análise é particularmente importante em sistemas corporativos que possuem dados históricos, integrações com múltiplos sistemas ou diferentes padrões de codificação.
CHAR Oracle vs CHAR PostgreSQL
O tipo CHAR representa valores de caracteres de tamanho fixo.
Apesar de existir tanto no Oracle quanto no PostgreSQL, a migração deve considerar cuidadosamente o comportamento de preenchimento, comparação e armazenamento.
Colunas CHAR são frequentemente utilizadas em códigos, flags, identificadores e campos legados. Alterar o tipo para varchar ou text pode modificar comportamentos esperados pela aplicação.
Antes de realizar a conversão, devem ser avaliados:
- tamanho definido;
- valores efetivamente armazenados;
- espaços à direita;
- comparações;
- índices;
- joins;
- regras de validação.
Oracle DATE vs PostgreSQL timestamp
Um dos pontos que mais exige atenção no comparativo de tipos de dados Oracle vs PostgreSQL é o tipo DATE.
No Oracle, DATE possui componentes de data e hora. No PostgreSQL, date representa somente a data, enquanto timestamp representa data e hora.
Por isso, uma coluna Oracle DATE que armazena horário normalmente deve ser analisada para determinar se o destino correto é:
- date;
- timestamp;
- timestamp with time zone.
Converter automaticamente Oracle DATE para PostgreSQL date pode resultar na perda da informação de horário.
Exemplo conceitual
Se uma coluna Oracle armazena valores como:
- 2026-08-28 08:30:00
- 2026-08-28 14:45:12
- 2026-08-28 23:59:59
ela não deve ser tratada simplesmente como uma coluna de data no PostgreSQL se o horário tiver relevância para a aplicação.
TIMESTAMP Oracle vs PostgreSQL
Os tipos TIMESTAMP apresentam correspondências mais diretas, mas ainda exigem validação.
Durante uma migração, devem ser avaliados:
- precisão dos segundos fracionários;
- timezone;
- conversões utilizadas pelo sistema;
- funções SQL relacionadas a data e hora;
- armazenamento de valores históricos;
- integrações entre fusos horários.
TIMESTAMP WITH TIME ZONE
Aplicações globais ou sistemas distribuídos podem depender de informações de fuso horário. Nesses casos, a conversão deve considerar não apenas o tipo da coluna, mas também a forma como a aplicação interpreta e apresenta os valores.
CLOB Oracle vs TEXT PostgreSQL
O CLOB é utilizado no Oracle para armazenamento de grandes volumes de texto.
No PostgreSQL, o tipo text é frequentemente utilizado para esse cenário.
Entretanto, a migração de CLOB não deve considerar apenas a estrutura da tabela. É necessário verificar:
- volume médio dos registros;
- maior tamanho encontrado;
- consultas realizadas;
- índices relacionados;
- integrações;
- processamento de grandes objetos;
- rotinas PL/SQL que manipulam o conteúdo.
BLOB Oracle vs bytea PostgreSQL
O BLOB é utilizado para dados binários, como arquivos e outros conteúdos não textuais.
No PostgreSQL, bytea é uma alternativa importante para armazenamento de dados binários dentro do banco.
Durante a migração, entretanto, é necessário avaliar a arquitetura da aplicação.
Um sistema que armazena milhões de documentos no Oracle pode exigir uma estratégia diferente de um sistema que mantém apenas pequenos objetos binários.
Devem ser analisados:
- tamanho dos objetos;
- quantidade de registros;
- frequência de leitura;
- frequência de atualização;
- backup;
- replicação;
- impacto sobre armazenamento;
- estratégia de recuperação.
RAW Oracle vs bytea PostgreSQL
RAW é utilizado para representar dados binários no Oracle.
O PostgreSQL oferece bytea para armazenamento de dados binários. Porém, a conversão deve considerar como os dados RAW são utilizados.
Se a aplicação realiza conversões específicas entre RAW, hexadecimal, strings ou identificadores, o código também pode precisar ser adaptado.
FLOAT e tipos de ponto flutuante
Oracle e PostgreSQL possuem mecanismos para trabalhar com números de ponto flutuante, mas a escolha do tipo deve considerar a necessidade de precisão.
Em PostgreSQL, tipos como real e double precision são destinados a números de ponto flutuante, enquanto numeric é utilizado quando a aplicação exige precisão decimal exata.
Essa distinção é especialmente importante para:
- cálculos financeiros;
- valores monetários;
- medições;
- estatísticas;
- modelos científicos;
- cálculos de engenharia.
Tipos de dados Oracle que exigem atenção especial
Alguns tipos e construções Oracle não possuem uma simples conversão direta ou podem exigir alterações arquiteturais.
LONG
LONG é um tipo legado do Oracle. Sistemas antigos podem possuir grandes volumes de dados armazenados dessa maneira.
Durante uma migração, é recomendável identificar essas colunas e avaliar a conversão para tipos modernos, como text, quando tecnicamente apropriado.
LONG RAW
LONG RAW também é uma estrutura legada destinada a dados binários. A conversão deve avaliar o conteúdo armazenado e a forma como as aplicações acessam esses dados.
ROWID
ROWID merece atenção porque representa uma característica específica do Oracle. Uma aplicação que utiliza ROWID diretamente não deve simplesmente copiar a coluna para PostgreSQL sem avaliar sua finalidade.
Em muitos projetos, a dependência de ROWID está presente em SQL, procedures, integrações ou mecanismos de atualização e precisa ser identificada durante o assessment.
Mapeamento de tipos de dados durante uma migração Oracle para PostgreSQL
Um projeto profissional deve criar uma matriz de conversão de tipos de dados.
Essa matriz pode conter:
- schema Oracle;
- tabela Oracle;
- coluna Oracle;
- tipo Oracle;
- precisão;
- escala;
- tamanho;
- tipo PostgreSQL proposto;
- regra de conversão;
- necessidade de transformação;
- impacto na aplicação;
- resultado da validação.
Exemplo de matriz de conversão
| Tipo Oracle | Destino PostgreSQL | Validação |
|---|---|---|
| NUMBER(10,2) | numeric(10,2) | Precisão e escala |
| NUMBER(10) | integer ou bigint | Faixa de valores |
| VARCHAR2(200) | varchar(200) | Tamanho e encoding |
| CHAR(1) | char(1) | Semântica do valor |
| DATE | timestamp | Preservação do horário |
| CLOB | text | Volume e aplicação |
| BLOB | bytea | Volume e estratégia de armazenamento |
| RAW | bytea | Formato e utilização |
O impacto dos tipos de dados no desempenho do PostgreSQL
A escolha do tipo de dado não afeta apenas a compatibilidade. Ela também pode influenciar desempenho e consumo de recursos.
Tipos mais adequados podem contribuir para:
- menor consumo de armazenamento;
- índices mais eficientes;
- melhor utilização de memória;
- menor volume de I/O;
- operações matemáticas mais adequadas;
- melhor planejamento das consultas.
Por isso, uma migração não deve buscar apenas reproduzir a estrutura Oracle. Em muitos casos, o projeto é uma oportunidade para revisar decisões de modelagem que foram acumuladas ao longo dos anos.
Tipos de dados e índices Oracle vs PostgreSQL
A mudança de tipo pode alterar o comportamento dos índices.
Uma coluna utilizada em filtros, joins e ordenações deve ser analisada em conjunto com seus índices e com as consultas da aplicação.
Alterações aparentemente pequenas, como trocar um tipo numérico por texto ou modificar a representação de datas, podem afetar o plano de execução.
Por isso, o processo deve combinar:
- análise do modelo de dados;
- mapeamento dos tipos;
- revisão dos índices;
- análise das consultas;
- testes de desempenho.
Tipos de dados e aplicações legadas Oracle
Ambientes Oracle de longa duração frequentemente possuem aplicações desenvolvidas em diferentes gerações tecnológicas.
Um mesmo banco pode conter aplicações Java, sistemas ERP, aplicações web, integrações, processos batch e componentes legados.
Nesses cenários, o tipo de dado pode estar refletido não apenas no banco, mas também em:
- código-fonte;
- classes de aplicação;
- ORMs;
- procedures;
- funções;
- scripts;
- interfaces;
- ETLs;
- relatórios;
- APIs.
Assim, o assessment deve procurar dependências fora do DDL.
Como validar o mapeamento de tipos de dados
A validação deve ocorrer em diferentes níveis.
Validação estrutural
Verificar se as tabelas, colunas, restrições e tipos foram criados corretamente no PostgreSQL.
Validação dos dados
Comparar quantidade de registros, valores, nulos, mínimos, máximos, somas e outras métricas relevantes.
Validação funcional
Executar as aplicações e processos que utilizam os dados migrados.
Validação de desempenho
Executar consultas críticas e comparar o comportamento antes e depois da migração.
Validação de integração
Testar interfaces, APIs, ETLs e demais sistemas dependentes.
Erros comuns no mapeamento Oracle vs PostgreSQL
- Converter todos os NUMBER para numeric sem avaliar a utilização;
- converter Oracle DATE diretamente para PostgreSQL date;
- ignorar precisão e escala;
- tratar VARCHAR2 apenas pelo tamanho declarado;
- ignorar CLOB e BLOB durante o planejamento;
- desconsiderar tipos legados;
- não analisar o código das aplicações;
- não validar dados após a carga;
- não testar consultas críticas;
- considerar que uma conversão automática significa migração concluída.
Ferramentas para apoiar a conversão de tipos
Ferramentas de migração podem automatizar parte importante do processo, principalmente na descoberta do esquema, conversão de DDL e movimentação dos dados.
Entretanto, automação não substitui a análise técnica.
Em projetos Oracle para PostgreSQL, ferramentas como o EDB Migration Toolkit podem auxiliar na migração, enquanto o trabalho de assessment e validação determina quais objetos e tipos precisam de tratamento específico.
A automação deve ser utilizada para acelerar tarefas repetitivas, mantendo revisão especializada nos pontos de maior risco.
Estratégia recomendada para projetos corporativos
Uma estratégia eficiente para o mapeamento de tipos de dados pode seguir as seguintes etapas:
- inventariar todos os schemas e tabelas;
- identificar os tipos utilizados;
- levantar precisão, escala e tamanhos;
- identificar tipos legados;
- mapear dependências das aplicações;
- criar regras de conversão;
- executar conversão em ambiente de teste;
- validar os dados;
- validar aplicações;
- executar testes de desempenho;
- corrigir incompatibilidades;
- documentar as regras;
- repetir o processo em ciclos até a estabilização.
Tipos de Dados Oracle vs PostgreSQL no contexto de um Assessment
O assessment é uma das etapas mais importantes para identificar riscos antes da migração definitiva.
Em um assessment Oracle para PostgreSQL, a análise dos tipos de dados pode revelar:
- tipos sem correspondência direta;
- colunas com grande volume de dados;
- dependências em tipos proprietários;
- uso de tipos legados;
- problemas de precisão;
- dependências em timezone;
- objetos binários;
- SQL incompatível;
- dependências de aplicações.
Essas informações ajudam a transformar uma migração genérica em um projeto planejado, com riscos e esforços conhecidos.
Conclusão
O comparativo Tipos de Dados Oracle vs PostgreSQL demonstra que uma migração de banco de dados exige muito mais do que encontrar nomes equivalentes entre os dois sistemas. NUMBER, VARCHAR2, DATE, TIMESTAMP, CLOB, BLOB, RAW e outros tipos precisam ser avaliados conforme suas características, seus valores reais e sua utilização pelas aplicações.
Um processo de migração bem estruturado utiliza o mapeamento de tipos como parte do assessment, define regras de conversão, executa testes e valida os dados antes da entrada em produção.
Para ambientes corporativos, críticos ou de grande porte, essa abordagem reduz riscos de perda de dados, incompatibilidades funcionais e problemas de desempenho após a migração para PostgreSQL.
FAQ — Perguntas Frequentes
Qual é o equivalente do Oracle NUMBER no PostgreSQL?
O tipo numeric ou decimal é frequentemente utilizado para valores de precisão exata. Entretanto, dependendo da precisão, escala e utilização, integer, bigint, real ou double precision também podem ser alternativas.
Oracle DATE é igual ao PostgreSQL date?
Não. Oracle DATE pode armazenar componentes de data e hora, enquanto PostgreSQL date representa apenas a data. Uma coluna Oracle DATE que depende do horário normalmente exige avaliação para conversão para timestamp.
Qual é o equivalente do VARCHAR2 no PostgreSQL?
Os equivalentes mais comuns são varchar e text. A escolha depende da necessidade de preservar limites explícitos de tamanho e das regras da aplicação.
Qual é o equivalente do CLOB no PostgreSQL?
O tipo text é normalmente utilizado para armazenar grandes volumes de texto no PostgreSQL.
Qual é o equivalente do BLOB no PostgreSQL?
O tipo bytea pode ser utilizado para armazenamento de dados binários. A arquitetura da aplicação e o volume dos objetos devem ser avaliados antes da conversão.
É possível converter automaticamente todos os tipos Oracle para PostgreSQL?
Parte significativa dos tipos pode ser convertida automaticamente ou semiautomaticamente, mas alguns tipos exigem regras específicas. Além disso, a conversão estrutural precisa ser validada contra os dados e as aplicações.
Os tipos de dados podem afetar o desempenho após a migração?
Sim. Tipos inadequados podem aumentar armazenamento, afetar índices, alterar operações matemáticas e influenciar o desempenho de consultas.
Por que o assessment é importante para os tipos de dados?
Porque ele permite identificar tipos utilizados, precisão, escala, dados legados, dependências e potenciais incompatibilidades antes da migração definitiva.
O EDB Migration Toolkit pode ajudar na conversão dos tipos?
Sim. Ferramentas de migração podem automatizar parte da conversão e movimentação dos objetos, mas regras específicas e validações continuam sendo necessárias em projetos corporativos.
Links Relacionados
- Migração Oracle para PostgreSQL
- Assessment Oracle PostgreSQL
- Planejamento de Migração Oracle para PostgreSQL
- Estratégia de Migração Oracle para PostgreSQL
- EDB Migration Toolkit
- PL/SQL no PostgreSQL
- Oracle SQL no PostgreSQL
- Compatibilidade Oracle PostgreSQL
- Oracle vs PostgreSQL
Recursos Oficiais
- Documentação oficial do PostgreSQL — Data Types
- Documentação PostgreSQL — Numeric Types
- Documentação PostgreSQL — Character Types
- Documentação PostgreSQL — Date/Time Types
- Documentação PostgreSQL — Binary Data
- EnterpriseDB — EDB
Modernize seu Banco de Dados com a Dominus Tech
👉 Planejando uma Migração Oracle para PostgreSQL?
A Dominus Tech é Parceira Gold da EnterpriseDB e apoia empresas em todas as etapas da modernização de bancos de dados Oracle para PostgreSQL. Nossa equipe atua em assessment, planejamento, análise de compatibilidade, arquitetura, migração, otimização de desempenho, alta disponibilidade, observabilidade e suporte especializado para ambientes PostgreSQL Enterprise.
✔ Parceira Gold da EnterpriseDB no Brasil
O planejamento adequado permite transformar uma migração complexa em um projeto estruturado, com riscos identificados, responsabilidades definidas, critérios de sucesso e estratégia de execução. A Dominus Tech pode apoiar sua organização desde a avaliação inicial até a estabilização do ambiente PostgreSQL em produção.
