De combien de RAM une base de données auto-hébergée a-t-elle besoin ?

Pour une app — une instance Postgres ou Redis plus son backend — 1,7-2 Go est un ensemble de travail réaliste, donc Small (8 $) convient. Plusieurs apps, ou une base de production avec une vraie concurrence, vous poussent vers Medium (12 $), et si d'autres machines doivent l'atteindre, une offre à IP dédiée. Dimensionnez selon l'ensemble de travail et le nombre de connexions, pas selon l'espoir.

Pourquoi auto-héberger plutôt qu'une base managée ?

Le contrôle. Vous obtenez tout le postgresql.conf, le superutilisateur et n'importe quelle extension — pgvector, PostGIS, TimescaleDB, pg_cron — des choses que les offres managées verrouillent souvent ou facturent en supplément. La contrepartie, c'est que les sauvegardes, le réglage et les mises à niveau sont à votre charge. Si vous voulez posséder la machine, c'est tout l'intérêt.

Un VPS partagé convient-il à une base de données de production ?

Pour une app petite à moyenne, oui. Pour de l'OLTP lourd — des centaines de transactions par seconde, des écritures critiques en latence — une machine à vCPU partagé est le mauvais outil, et nous le dirons plutôt que de vous en vendre une. Les E/S disque et une horloge garantie comptent là, et les offres partagées ne promettent ni l'un ni l'autre.

Comment laisser mes autres serveurs se connecter à la base ?

Liez Postgres à la bonne interface, n'ouvrez le port qu'aux IP qui en ont besoin, et utilisez une offre avec une IPv4 dédiée pour que l'adresse soit stable et joignable. N'exposez jamais 5432 à tout Internet — protégez-le par pare-feu vers vos serveurs d'application et exigez TLS.

Dois-je vous donner une pièce d'identité ?

Non. Un e-mail pour s'inscrire, des USDC ou USDT pour payer. Sans documents, root en une minute environ.

VPS pour une base de données

Auto-hébergez PostgreSQL ou Redis sur un VPS avec root complet — tout le postgresql.conf, des extensions qu'un service managé ne vous laissera pas installer, et des limites honnêtes sur ce qu'une machine partagée peut et ne peut pas encaisser. Dès 8 $/mois.

Il y a un moment précis où une base managée cesse d'être pratique et devient un mur. Vous voulez une extension que l'offre ne propose pas. Vous voulez voir le vrai plan de requête et régler work_mem. Vous voulez un superutilisateur. Un service managé est un excellent choix par défaut jusqu'au moment où vous avez besoin de posséder la chose — et alors un VPS avec root complet est la réponse honnête.

Cette page porte sur le fait de faire tourner votre propre PostgreSQL ou Redis correctement, et d'être clair sur les cas où une machine partagée est le bon choix et ceux où elle ne l'est pas.

Ce dont une base de données a réellement besoin

Les bases de données se soucient de deux choses dont un serveur de jeu ne se soucie pas : la mémoire pour l'ensemble de travail et les E/S disque. La forme approximative :

Une app — une instance Postgres (ou Redis) plus un service backend. L'ensemble de travail fait généralement 1,7-2 Go. Small (8 $) le gère sans drame.
Quelques apps, ou une vraie concurrence de production — plus de connexions, des caches plus grands, des tâches de fond. Medium (12 $) vous donne la marge.
D'autres machines doivent l'atteindre — vous voulez une adresse stable et routable, donc une offre à IPv4 dédiée (Small-IP 16 $ et plus). Plus de détails ci-dessous.

Redis est encore plus léger — il est limité par la mémoire, donc dimensionnez l'offre selon votre jeu de données plus l'overhead et c'est réglé. Postgres est celui qui récompense un peu de réglage.

La vraie raison d'auto-héberger : le contrôle

C'est là qu'un VPS gagne sa place. Sur votre propre machine, vous obtenez :

Tout le postgresql.conf — shared_buffers, work_mem, max_connections, les réglages WAL, tout ça, réglé selon votre charge plutôt que selon les valeurs par défaut d'un fournisseur.
N'importe quelle extension. pgvector pour les embeddings et la recherche sémantique, PostGIS pour le géospatial, TimescaleDB pour les séries temporelles, pg_cron, pg_stat_statements — installez ce dont vous avez besoin. Les offres managées restreignent fréquemment la liste des extensions ou la réservent à une offre supérieure.
Le superutilisateur et l'OS en dessous. Vous pouvez déplacer le répertoire de données, régler le noyau, lancer pg_dump selon votre propre calendrier, et mettre en place une réplication en streaming vers une autre machine si vous le voulez.

Si rien de cela ne compte pour vous, une base managée convient vraiment et vous devriez en utiliser une. Cette page est pour le cas où cela compte.

Là où une machine partagée est le mauvais outil

Pour être direct : un VPS à vCPU partagé n'est pas conçu pour l'OLTP lourd — des centaines de transactions par seconde avec des écritures critiques en latence. Cette charge vit ou meurt sur des E/S disque garanties et une horloge stable, et les offres partagées ne promettent ni l'une ni l'autre. Si c'est votre cas, il vous faut du matériel dédié, et nous préférons vous le dire maintenant plutôt que de voir votre latence p99 nous embarrasser tous les deux.

Pour le cas bien plus courant — une base derrière une app, un outil interne, un magasin analytique, un cache — une offre partagée est exactement ce qu'il faut.

Les sauvegardes ne sont pas facultatives

Auto-héberger signifie que les sauvegardes sont votre travail, et la seule règle est : faites-les avant d'en avoir besoin. Pour Postgres, pg_dump en cron pour des sauvegardes logiques, ou l'archivage WAL pour une récupération à un instant précis sur tout ce qui vous tient vraiment à cœur. Expédiez les dumps hors de la machine — vers un stockage objet ou un autre serveur — pour qu'un disque mort n'emporte pas les sauvegardes avec lui. Testez une restauration au moins une fois. Une sauvegarde que vous n'avez jamais restaurée est un espoir, pas une sauvegarde.

Laisser d'autres serveurs se connecter

Si la base ne sert qu'une app sur la même machine, liez-la à localhost et c'est réglé — rien à exposer. Dès qu'une autre machine doit entrer, deux choses changent :

Il vous faut une adresse stable et routable — c'est une offre à IPv4 dédiée (Small-IP 16 $, Medium-IP 20 $). Les offres NAT partagent une adresse, ce qui convient pour le sortant mais pas pour être une base que d'autres serveurs appellent.
Vous la protégez sévèrement par pare-feu. N'ouvrez 5432 (ou 6379) qu'aux IP spécifiques qui en ont besoin, jamais à 0.0.0.0/0, et exigez TLS. Un port Postgres ouvert sur l'Internet public est trouvé en quelques minutes.

Choisir l'offre

Configuration	Offre
BD derrière une app, localhost uniquement	Small (8 $)
Quelques apps / concurrence de production	Medium (12 $)
D'autres serveurs doivent se connecter	Small-IP (16 $) / Medium-IP (20 $)
OLTP lourd, des centaines de TPS	matériel dédié, pas un VPS partagé

La plupart des bases de données auto-hébergées commencent sur Small et grandissent vers Medium ou une offre à IP dédiée à mesure qu'elles prennent en charge plus d'apps ou de clients externes.

Pourquoi ici

Le root complet signifie que c'est votre base de données, de bout en bout — chaque ligne de config, chaque extension, votre propre calendrier de sauvegarde, sans offre décidant ce que vous êtes autorisé à installer. Le paiement est en crypto (USDC ou USDT sur Base, Ethereum ou Polygon), sans KYC, sans documents. Root en 60 secondes environ après le paiement, et vous pouvez avoir Postgres acceptant des connexions quelques minutes plus tard.

Le récapitulatif honnête : auto-hébergez quand vous voulez le contrôle — extensions, réglage, superutilisateur — et quand votre charge est modérée. Pour la base d'une app petite à moyenne, une offre partagée est le bon outil. Pour des centaines de TPS d'OLTP critique en latence, ce ne l'est pas, et nous le dirons. Prêt ? Choisissez une offre.