Guides et tutoriels PostgreSQL
Ces guides portent sur Postgres lui-même. Chacun part d’un problème que vous pouvez rencontrer en production, le reproduit avec du SQL à coller dans psql et se termine par une correction que vous pouvez vérifier. Ils visent PostgreSQL 17, la version utilisée par Relyt One, et l’essentiel de leur contenu vaut pour toute version récente de Postgres. Suivez le parcours de lecture ci-dessous dans l’ordre, ou allez directement au guide qui correspond à votre problème.
11 articles publiés
Commencer ici
Quatre guides, dans l’ordre que nous conseillons : modifier un schéma sans verrouiller la table, faire utiliser vos index par les requêtes, garder la sécurité au niveau des lignes fermée, puis vérifier ce qui change si vous venez de Postgres 18.
- Migrations Postgres qui verrouillent la table : le verrou pris par chaque ALTER TABLE, et comment déployer sans risquePourquoi un ALTER TABLE d’une ligne peut bloquer toutes les requêtes sur une table, quel verrou prend chaque migration courante sous PostgreSQL 17, lesquelles réécrivent la table, et les techniques lock_timeout, NOT VALID et CONCURRENTLY qui gardent la production en marche.
- Pourquoi Postgres n’utilise pas votre index : sept causes, avec des sorties EXPLAIN reproductiblesVous avez créé l’index et EXPLAIN affiche toujours un sequential scan. Sept raisons pour lesquelles PostgreSQL ignore un index (fonctions, casts, jokers, sélectivité, statistiques périmées, ordre des colonnes, tables minuscules), chacune avec une reproduction et un correctif.
- Cinq façons dont la sécurité au niveau des lignes laisse tout passerLa sécurité au niveau des lignes est la meilleure défense contre une clause WHERE oubliée, jusqu’à ce qu’elle cesse de s’appliquer sans bruit. Cinq façons dont elle laisse tout passer sur PostgreSQL 17, chacune avec une reproduction, un correctif et une requête de catalogue qui la détecte en CI.
- Vous venez de Postgres 18 ? Ce qu’il faut changer pour Postgres 17Relyt One fonctionne sous PostgreSQL 17. Si votre schéma ou vos habitudes viennent de Postgres 18, voici ce qui échoue sur 17, ce qu’il faut écrire à la place et comment charger un dump réalisé sur 18, chaque extrait ayant été exécuté sur les deux versions.
Autres articles avec l’étiquette Postgres
Flux RSS
Pourquoi les identifiants Postgres sautent des numéros, et comment corriger les erreurs « duplicate key » après une importation
D’où viennent les trous dans les colonnes serial et identity de PostgreSQL (annulations, ON CONFLICT, plantages, CACHE), pourquoi les insertions échouent avec duplicate key value violates unique constraint après une importation de données, une requête qui réinitialise toutes les séquences, l’épuisement des identifiants integer et des numéros de facture sans trous. Chaque instruction a été reproduite sur Postgres 17.11.
Postgres comme file d’attente de tâches : FOR UPDATE SKIP LOCKED, bien fait
Comment construire une file d’attente de tâches en arrière-plan dans PostgreSQL 17 avec SELECT ... FOR UPDATE SKIP LOCKED : pourquoi le SELECT-puis-UPDATE naïf réserve deux fois la même tâche, pourquoi FOR UPDATE seul fait attendre les workers, baux et nouvelles tentatives, LISTEN/NOTIFY, vacuum, et ce que des workers qui interrogent en boucle font à une instance de calcul serverless. Chaque instruction a été reproduite sur Postgres 17.11.
INSERT ... ON CONFLICT ou MERGE dans Postgres : quel upsert utiliser, et les erreurs que chacun déclenche
Quand faire un upsert avec INSERT ... ON CONFLICT et quand utiliser MERGE dans PostgreSQL 17, pourquoi MERGE peut échouer avec une erreur de clé dupliquée en cas de concurrence, et comment corriger « cannot affect row a second time », un RETURNING vide et « no unique or exclusion constraint matching the ON CONFLICT specification ». Chaque instruction a été reproduite sur Postgres 17.11.
Ce qui casse derrière le pooling en mode transaction de PgBouncer, et comment corriger chaque cas
Pourquoi vous obtenez « prepared statement already exists », des paramètres qui fuient d’une requête à l’autre et des verrous consultatifs qui ne verrouillent rien derrière un pooler en mode transaction, reproduits sur PgBouncer 1.24 et PostgreSQL 17, avec la correction de chaque cas et une règle pour savoir quand utiliser plutôt la connexion directe.
Premiers pas avec l’authentification gérée de Relyt One
Un guide pas à pas pour créer une application Next.js multi-utilisateur sur Relyt One. Activez l’authentification gérée sur une branche, connectez vos utilisateurs, vérifiez leurs JWT avec @relyt/auth et laissez la sécurité au niveau des lignes de Postgres séparer les lignes de chaque utilisateur.
L’authentification gérée de Relyt One, désormais en préversion
Inscription, connexion, sessions et organisations pour les utilisateurs de votre application, exécutées à côté de votre branche et stockées dans votre propre base de données. Les jetons sont des JWT EdDSA de courte durée que vous vérifiez avec JWKS, et la sécurité au niveau des lignes fait le reste.
Découvrez Relyt One : le Postgres serverless qui se branche comme du code
Relyt One est un PostgreSQL 17 serverless avec des branches en copie sur écriture, un calcul qui se suspend en cas d’inactivité, une recherche vectorielle intégrée et une authentification gérée. Voici comment il fonctionne et comment passer de la connexion à une base de données avec branches en cinq minutes.
D’autres articles sont disponibles en anglais. Articles en anglais