Bases de données managées — Hikube

PostgreSQL, MySQL, Redis,
 MongoDB,  ClickHouse.

kubectl apply — c'est tout. 

Cinq bases de données entièrement managées sur Hikube. Réplication automatique, failover, sauvegardes S3, credentials auto-générés. Zéro maintenance du moteur de base de données. 

CONTACTEZ NOS EXPERTS DOCUMENTATION

 5 BDD

 PostgreSQL · MySQL · Redis · MongoDB · ClickHouse 

 HA native 

 Réplication + failover automatique 

 S3 backup 

 Sauvegardes chiffrées planifiées 

 0 config

 Credentials générés automatiquement 
Comparatif

Le bon moteur pour chaque usage 

Chaque service repose sur un opérateur Kubernetes reconnu : CloudNativePG, MariaDB-Operator, Spotahome, Altinity. La gestion du cycle de vie (déploiement, réplication, failover, backup) est entièrement automatisée. 

Service
Type
réplication
cas d’usage
PostgreSQL
Relationnel
Streaming + Failover
Applications transactionnelles, APIs, SaaS
MySQL
Relationnel
Binog + auto-failover
CMS, e-commerce, applications legacy
Redis
Clé-valeur
Sentinel + auto-failover
Cache, sessions, files d'attente
MongoDB
Documents
Replica Set + élection
APIs, catalogues, données semi-structurées
ClickHouse
Analytique (OLAP)
ReplicatedMergeTree + Keeper
Analytics, logs, data lake, OLAP
SERVICES

Chaque base de données en détail 

Postgres

Failover automatique Streaming replication PITR

 Service PostgreSQL managé basé sur CloudNativePG. Un primary accepte les écritures, les réplicas sont synchronisés en streaming replication depuis le primary. En cas de panne, un réplica est automatiquement promu sans intervention manuelle.

Les réplicas sont répartis sur des datacenters différents. Avec replicas: 3, vous obtenez 1 primary + 2 standbys sur 3 sites. 

  •  Sauvegardes WAL + PITR
    Les WAL sont archivés en continu vers S3. Restauration possible à n'importe quel instant entre deux backups.
  • Utilisateurs et bases déclaratifs
    Déclarez vos users, databases, rôles admin et readonly directement dans le manifeste. Credentials stockés dans un Secret auto-généré.
  • Extensions PostgreSQL
    Activez uuid-ossp, pgcrypto, hstore et d'autres extensions par base dans la section databases[name].extensions.
  • Réplication synchrone optionnelle
    Configurez quorum.minSyncReplicas pour qu'une transaction ne soit validée qu'après confirmation d'un réplica.

Recommandation production

replicas: 3 + quorum.minSyncReplicas: 1 pour un bon compromis performance / durabilité.
yaml
apiVersion: apps.cozystack.io/v1alpha1
kind: Postgres 
metadata:
  name: example
spec:
  replicas: 3
  resourcesPreset: micro
  size: 10Gi
  users:
    user1:
    password: strongpassword
  databases:
    myapp:
    roles:
      admin:
      - user1
      readonly:
      - user2
    extensions:
    - uuid-ossp
  quorum:
    minSyncReplicas: 0
    maxSyncReplicas: 0
  backup:
    enabled: false
    # destinationPath: s3://bucket/path/
    # endpointURL: https://prod.s3.hikube.cloud
    # retentionPolicy: 30d 


 
Pourquoi managé

Moins d'ops, plus de code métier 

 Maintenir une base de données en production, c'est gérer des mises à jour de version, surveiller la réplication, configurer les sauvegardes, tester les procédures de restauration et intervenir à 3h du matin quand un primary tombe. Ce n'est pas de la valeur ajoutée, c'est de l'infrastructure.

Sur Hikube, cette charge disparaît. Vous déclarez ce que vous voulez, type de base, nombre de réplicas, taille, utilisateurs, et l'opérateur provisionne, réplique, bascule en failover et sauvegarde automatiquement. Vos équipes se concentrent sur les requêtes, le schéma et les performances applicatives, pas sur l'infrastructure.

Les bases de données sont hébergées en Suisse, dans le même datacenter que vos clusters Kubernetes Hikube. La latence entre votre application et votre base est minimale et vos données ne quittent pas l'espace européen. 

markup-cropped-2

Failover automatique sans intervention


Panne du primary ? L'opérateur promeut un réplica en quelques secondes. Aucune alerte à 3h du matin, aucune action manuelle. 

markup-cropped-2

Scaling déclaratif


Changez replicas ou size dans le manifeste, appliquez. L'opérateur s'occupe du rolling update sans downtime. 

markup-cropped-2

Sauvegardes testables et planifiées

WAL archiving pour PostgreSQL, Restic pour MySQL / MongoDB / ClickHouse. Rétention configurable, restauration documentée. Une sauvegarde qui n'a jamais été testée n'est pas une sauvegarde. 

markup-cropped-2

Credentials Kubernetes-natifs


Chaque base génère un Secret dans votre namespace. Injectez-le dans vos pods via envFrom, aucune clé en clair dans vos manifestes ou dépôts Git. 

Cas d'usage

Quelle base pour quel besoin ? 

Chaque moteur a ses forces. Voici les situations concrètes où chacun s'impose et pourquoi. 

Application SaaS multi-tenant

Chaque client dispose d'un schéma isolé dans la même instance PostgreSQL. Transactions ACID, contraintes d'intégrité, jointures complexes. Le réplica secondaire absorbe les requêtes de reporting sans impacter le primary. 

replicas: 3 · quorum: 1 · WAL backup

CMS et plateforme e-commerce

WordPress, Magento, PrestaShop. Toutes ces applications sont conçues pour MySQL. Migration depuis un MySQL auto-hébergé sans changement de code. Le LoadBalancer externe donne un accès direct depuis les outils d'administration. 

replicas: 3 · external: true · Restic backup

Cache de sessions et rate limiting

Stockage de sessions utilisateurs dans une API haute fréquence. Latence sub-milliseconde, expiration automatique des clés (TTL), compteurs atomiques pour le rate limiting. Le Sentinel garantit la continuité même si le master tombe. 

replicas: 3 · authEnabled: true · storageClass: local

Catalogue produits et API REST

Catalogue e-commerce avec des attributs variables selon la catégorie (vêtements, électronique, alimentaire). Le schéma flexible de MongoDB évite les migrations de table à chaque nouveau type de produit. Indexation sur n'importe quel champ imbriqué..

replicas: 3 · Replica Set · Restic backup

Analytics temps réel sur logs applicatifs

Ingestion de milliards d'événements (logs, métriques, clics). Les requêtes agrégées s'exécutent en quelques secondes même sur des tables de plusieurs téraoctets grâce au stockage colonne et au sharding. Idéal pour les dashboards BI et les alertes temps réel. 

shards: 2 · replicas: 2 · Keeper: 3

Stack complète pour une application ML

PostgreSQL pour les données structurées (utilisateurs, jobs), Redis pour la file de jobs ML et le cache des résultats, MongoDB pour les artefacts et métadonnées des modèles (structure variable), ClickHouse pour les métriques d'inférence en temps réel. 

PG + Redis + Mongo + ClickHouse
Fonctionnalités communes

Ce que partagent tous les services  

Chaque base de données managée sur Hikube expose les mêmes mécanismes fondamentaux, quelle que soit la technologie choisie. 

  • Déploiement déclaratif via kubectl
    Un manifeste YAML, un kubectl apply. L'opérateur provisionne et maintient le cluster automatiquement.

  • Credentials auto-générés dans un Secret
    Chaque service génère un Secret Kubernetes <service>-<name>-credentials contenant les mots de passe. Aucune configuration manuelle des accès.

  • Sauvegardes S3 intégrées
    PostgreSQL utilise WAL archiving + CloudNativePG. MySQL et ClickHouse utilisent Restic. Tous vers n'importe quel endpoint S3 compatible y compris les buckets Hikube.

  • Presets de ressources ou configuration explicite
    resourcesPreset (nano à 2xlarge) pour démarrer vite. resources.cpu et resources.memory pour les environnements de production. Les deux sont mutuellement exclusifs.

Gamme
Ration
USAGE RECOMMANDÉ
nano
250m
128 Mi
micro
500m
256 Mi
small
1 CPU
512 mi
medium
1 GPU
1 Gi
large
2 GPU
2 Gi
xlarge
4 GPU
4 Gi
2xlarge
8 GPU
8 Gi
FAQ

Questions sur les bases de données managées

Puis-je sauvegarder vers les buckets S3 Hikube ?

Oui, c'est le cas d'usage recommandé. Créez un bucket Hikube, récupérez les credentials depuis le Secret généré, et renseignez-les dans la section backup de votre manifeste. Les sauvegardes restent ainsi dans la même infrastructure, en Suisse.

Quelle est la différence entre resourcesPreset et resources ?

resourcesPreset applique un profil prédéfini (nano, micro, small…). C'est le moyen le plus simple de démarrer. Si vous définissez resources.cpu et resources.memory explicitement, le preset est entièrement ignoré. Les deux sont mutuellement exclusifs — ne les combinez pas dans le même manifeste.

ClickHouse est-il adapté à mes requêtes transactionnelles ?

Non. ClickHouse est un moteur OLAP optimisé pour les requêtes analytiques — agrégations, scans de colonnes sur de grands volumes. Il n'est pas adapté aux opérations transactionnelles fréquentes (UPDATE / DELETE unitaires, transactions ACID). Pour du transactionnel, utilisez PostgreSQL ou MySQL sur Hikube.

Le service MySQL est-il compatible avec mes applications MySQL existantes ?

Oui. Le service MySQL sur Hikube repose sur MariaDB, un fork open-source de MySQL entièrement compatible avec le protocole, la syntaxe et les clients MySQL. Vos applications, drivers et ORM fonctionnent sans modification.

Combien de réplicas Redis faut-il pour le failover automatique ?

Minimum 3. Redis Sentinel a besoin d'un quorum — une majorité de Sentinels (2 sur 3) doit s'accorder pour décider d'un failover. Avec replicas: 3, vous obtenez 3 pods Redis et 3 pods Sentinel, ce qui garantit le quorum même si un Sentinel est indisponible.