De nombreuses entreprises qui migrent d'Oracle à PostgreSQL supposent que le principal défi sera de Différences de syntaxe SQL.

Mais en réalité, les changements les plus importants sont architectural.

Si vous venez d'un environnement Oracle (RAC, Exadata, Enterprise), il est essentiel de comprendre ces différences car elles ont une incidence directe :

• Optimisation des performances
• Dépannage
• Planification des capacités
• Stratégies de mise à l'échelle

Ci-dessous 8 différences architecturales clés entre Oracle et PostgreSQL qui ont le plus d'impact sur les performances.

1. Modèle de processus

Oracle : Architecture à mémoire partagée

Oracle s'appuie fortement sur structures de mémoire partagée à l'intérieur du SGA (System Global Area).

Architecture typique :

User process
   |
Server process
   |
SGA (shared memory)

Les principaux éléments de la SGA sont les suivants

SGA
 ├ Buffer cache
 ├ Shared pool
 ├ Redo log buffer
 └ Large pool

De nombreuses sessions accèdent à la les mêmes structures de mémoire simultanément.

Pour contrôler la concurrence, Oracle utilise des mécanismes tels que

• Loquets
• Mutex
• Verrouillage du cache de la bibliothèque

PostgreSQL : Processus par connexion

PostgreSQL utilise un architecture processus par connexion.

Client
   |
PostgreSQL backend process

Chaque connexion génère un processus distinct pour le système d'exploitation.

Exemple :

postgres
 ├ backend process 1
 ├ backend process 2
 ├ backend process 3

La mémoire partagée est plus petite et plus simple.

Les principaux domaines partagés sont les suivants

shared_buffers
wal_buffers

Impact sur les performances

PostgreSQL ne peut pas gérer efficacement les des milliers de connexions directes.

C'est la raison pour laquelle les pools de connexion tels que :

pgBouncer
pgpool

sont couramment utilisés dans la production.

2. Contrôle de la concomitance (MVCC)

Oracle et PostgreSQL utilisent tous deux MVCC (Multi-Version Concurrency Control), mais ils la mettent en œuvre différemment.

Oracle MVCC

Oracle stocke les versions précédentes des lignes dans Annuler les tablespaces.

Exemple d'opération :

UPDATE table

Oracle écrit la version précédente dans :

UNDO

Lorsqu'une requête a besoin d'un cliché plus ancien, Oracle le reconstruit à l'aide de la fonction UNDO.

PostgreSQL MVCC

Magasins PostgreSQL les versions de ligne directement dans le tableau.

Exemple de mise à jour :

UPDATE row

PostgreSQL crée un fichier nouvelle version de la ligne.

old row (dead)
new row (visible)

Impact sur les performances

Comme les anciennes versions des lignes restent à l'intérieur des tables, les tables PostgreSQL s'agrandissent avec le temps.

C'est pourquoi PostgreSQL exige :

VACUUM

En l'absence d'un nettoyage adéquat, on obtient :

table bloat
index bloat

Il s'agit de l'un des Principales différences conceptuelles pour les administrateurs de bases de données Oracle.

3. VACUUM vs Oracle Automatic Cleanup

Oracle gère automatiquement les anciennes versions de lignes à l'aide du système UNDO.

PostgreSQL doit être nettoyé périodiquement par ASPIRATEUR.

Il en existe deux types principaux :

VACUUM
AUTOVACUUM

Autovacuum supprime automatiquement les tuples morts.

Si l'autovacuum n'est pas correctement réglé, vous risquez de rencontrer des problèmes :

table bloat
slow sequential scans
very large indexes

Implication sur les performances

Dans les environnements PostgreSQL :

autovacuum tuning is critical

De nombreux problèmes de production ont leur origine :

autovacuum not aggressive enough

4. WAL vs Oracle Redo Logs

Les deux systèmes utilisent l'enregistrement des données à l'avance pour la récupération en cas d'accident.

Oracle Logging

Oracle utilise journaux de rétablissement (redo logs).

Les changements s'enchaînent :

redo log buffer
→ redo log files

Processus d'arrière-plan responsable :

LGWR

Journalisation PostgreSQL

PostgreSQL utilise WAL (Write Ahead Logging).

Les données sont écrites dans :

WAL segments

Emplacement :

pg_wal/

Exemple de fichier :

00000001000000000000000A

Implication sur les performances

Les performances de PostgreSQL dépendent souvent de :

WAL throughput
disk latency
checkpoint tuning

Les paramètres importants sont les suivants

checkpoint_timeout
max_wal_size
wal_buffers

5. Comportement de l'index

Les index Oracle restent relativement stables même en cas de mises à jour importantes.

Les index PostgreSQL se comportent différemment à cause de MVCC.

Lorsqu'une ligne est mise à jour :

UPDATE row

PostgreSQL crée :

new row version
new index entry

L'entrée d'index précédente est conservée jusqu'à ce que le vide soit fait.

Implication sur les performances

Les index PostgreSQL peuvent gonfler de manière significative.

Un entretien périodique peut être nécessaire :

REINDEX
VACUUM FULL

Ou des vues de contrôle telles que :

pg_stat_all_indexes

6. Différences entre les optimiseurs de requêtes

Oracle dispose d'un optimiseur extrêmement sophistiqué avec des fonctionnalités telles que :

adaptive plans
parallel query
optimizer hints
statistics feedback

L'optimiseur de PostgreSQL est plus simple et s'appuie principalement sur :

statistics
cost model

Les statistiques sont stockées dans :

pg_statistic

Mise à jour par :

ANALYZE

Implication sur les performances

Dans PostgreSQL :

bad statistics = bad execution plans

C'est pourquoi analyse de l'autovacuum est important.

7. Exécution parallèle

Oracle parallel query est très avancé.

Exemple :

SELECT /*+ PARALLEL(8) */ ...

PostgreSQL a ajouté le parallélisme plus tard.

Les opérations les plus courantes sont les suivantes

Parallel Seq Scan
Parallel Hash Join
Parallel Aggregate

Contrôlé par des paramètres tels que

max_parallel_workers_per_gather
max_worker_processes

Implication sur les performances

Le parallélisme dans PostgreSQL est moins agressif qu'Oracle, mais toujours précieux pour :

large analytical queries

8. Architecture des grappes

C'est sur ce point qu'Oracle et PostgreSQL diffèrent le plus.

Oracle RAC

Oracle RAC permet plusieurs nœuds pour écrire simultanément.

Node1
Node2
Node3

Tous les nœuds accèdent au même base de données partagée.

Réplication PostgreSQL

PostgreSQL utilise un architecture à une seule écriture.

Primary
   |
Standby replicas

Les méthodes de réplication comprennent

streaming replication
logical replication

Implication sur les performances

Les stratégies de mise à l'échelle diffèrent considérablement.

Mise à l'échelle d'Oracle RAC :

add nodes → more write capacity

Mise à l'échelle de PostgreSQL :

read scaling → replicas
write scaling → sharding

Résumé de l'architecture Oracle vs PostgreSQL

Les 3 choses qui surprennent le plus les administrateurs de bases de données Oracle

Lors de migrations réelles, ces trois problèmes apparaissent fréquemment.

1. Problèmes liés à l'autovacuum

Symptômes :

tables growing
indexes growing
slow queries

2. Trop de connexions

PostgreSQL ne s'adapte pas bien à un grand nombre de connexions.

1000+ connections

La solution typique est la suivante :

pgBouncer

3. Goulets d'étranglement WAL

Les charges de travail lourdes en écriture peuvent saturer :

WAL disk throughput

Réflexions finales

La migration d'Oracle vers PostgreSQL ne se limite pas à la traduction du langage SQL.

Il faut comprendre différences architecturales fondamentales qui influencent les performances, l'échelle et les pratiques opérationnelles.

Une fois ces différences comprises, PostgreSQL devient une plateforme extrêmement puissante et flexible pour les systèmes de données modernes.