Managed databases - Hikube

PostgreSQL, MariaDB, Redis, MongoDB, ClickHouse.
kubectlapply - that's it.

Five fully managed databases on Hikube. Automatic replication, failover, S3 backups, auto-generated credentials. Zero database engine maintenance.

CONTACT OUR EXPERTS DOCUMENTATION

PostgreSQL

Relationship

Streaming + Failover

Transactional applications, APIs, SaaS

MariaDB

Relationship

Binog + auto-failover

CMS, e-commerce, legacy applications

Redis

Value key

Sentinel + auto-failover

Cache, sessions, queues

MongoDB

Documents

Replica Set + election

APIs, catalogs, semi-structured data

ClickHouse

Analytical (OLAP)

ReplicatedMergeTree + Keeper

Analytics, logs, data lake, OLAP

Postgres

Automatic failover Streaming replication PITR

Managed PostgreSQL service based on CloudNativePG. A primary accepts writes, and replicas are synchronized by streaming replication from the primary. In the event of failure, a replica is automatically promoted without manual intervention.

Replicas are distributed across different datacenters. With replicas: 3, you get 1 primary + 2 standbys on 3 sites.

WAL + PITR backups
WALs are continuously archived to S3. Restoration possible at any time between two backups.
Declarative users and databases
Declare your users, databases, admin and readonly roles directly in the manifest. Credentials stored in an auto-generated Secret.
PostgreSQL extensions
Enable uuid-ossp, pgcrypto, hstore and other extensions per database in the databases[name].extensions section.
Optional synchronous replication
Configure quorum.minSyncReplicas so that a transaction is committed only after confirmation of a replica. uement.

Production recommendation

replicas: 3 + quorum.minSyncReplicas: 1 for a good compromise between performance and durability.

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

MariaDB

Automatic failover Group replication Restic backup

Managed service based on MariaDB-Operator. MariaDB is an open-source fork of MySQL, fully compatible with MySQL clients and protocols - your applications run unchanged. With replicas: 3, you get 1 primary + 2 replicas distributed over different datacenters.

Replication uses MariaDB's binlog. If the primary fails, the operator automatically promotes a replica.

100% MySQL compatible
MySQL clients, protocols and drivers work without adaptation. The CRD is called MySQL, the operator uses MariaDB internally.
Restic to S3 backups
Encrypted snapshots with configurable retention (--keep-last, --keep-daily). Stored on any compatible S3 bucket.
Optional external exposure
external: true creates a LoadBalancer service with public IP for out-of-cluster connections.
Manual switchover
Scheduled switchover from primary to another node via manifest modification - useful for maintenance.

External exposure

Avoid external: true if your applications are running in the same cluster. Prefer connection via the ClusterIP service to limit the exposure surface.

yaml

apiVersion: apps.cozystack.io/v1alpha1
kind: MariaDB
metadata:
  name: example
spec:
  replicas: 3
  resourcesPreset: nano
  size: 10Gi
  external: true
  users:
    user1:
    password: hackme
    maxUserConnections: 1000
  databases:
    myapp1:
      roles:
      admin:
        - user1
      readonly:
        - user2
  backup:
    enabled: false
    # resticPassword: <password>
    # s3Bucket: s3. example.org/mysql
    # schedule: "0 2 * * *"

Redis

In-memory Sentinel Auto-failover

Managed Redis service with master-replicas architecture and Redis Sentinel. With replicas: 3, you get 3 Redis pods (master + replicas) and 3 Sentinel pods for supervision. The Sentinel detects master failure and automatically promotes a replica.

Data is persisted via RDB/AOF on Kubernetes volumes. The password is auto-generated and stored in a Secret.

Automatic sentinel and quorum
3 Sentinel pods minimum to guarantee quorum (2/3 majority). Failover is triggered by consensus between Sentinels.
Default authentication
authEnabled: true by default - auto-generated password. Disable only in isolated development.
RDB/AOF persistence
Data survives restarts. Configure storageClass according to your performance vs. resilience needs.
Connection via Sentinel recommended
Connect your apps via the rfs-redis-<name> service (port 26379) to automatically track the master after failover.

StorageClass and replication

With replicas > 1, use storageClass: local - Redis replication already provides HA. With replicas: 1, use storageClass: replicated.

yaml

apiVersion: apps.cozystack.io/v1alpha1
kind: Redis
metadata:
  name: example
spec:
  replicas: 3 # 3 Redis + 3 Sentinel 
  resourcesPreset: nano
  size: 1Gi
  authEnabled: true # Mot de passe auto-généré
  external: false 


Bash
# Récupérer le mot de passe
kubectl get secret redis-example-auth \
  -o json 1 jq -r \
  ' data | to_entries[] | "\ (.key): \. value |@base64d)"'

MongoDB

Vector Search Replica Set Atlas-compatible

Managed MongoDB service based on the MongoDB Kubernetes Operator. Each instance deploys a Replica Set - a primary accepts writes, secondaries receive changes in oplog replication. In the event of a primary failure, an automatic election designates a new primary among the secondaries.

MongoDB is a document-oriented database (BSON/JSON) with no fixed schema, particularly suited to semi-structured data, REST APIs and applications with frequently changing data models.

Replica Set with automatic election
3 members minimum for quorum - 1 primary + 2 secondaries. The primary is elected automatically by majority vote in the event of a failure.
Document-oriented database
BSON (binary JSON) storage, flexible schema, indexing on any field. Ideal for catalogs, user profiles, IoT data, APIs.
Integrated S3 backups
Snapshots via Restic to any compatible S3 bucket - including Hikube Object Storage buckets.
Auto-generated credentials
Users and passwords declared in the manifest, stored in an auto-generated Kubernetes Secret.

Production recommendation

replicas: 3 + quorum.minSyncReplicas: 1 for a good compromise between performance and durability.

yaml

apiVersion: apps.cozystack.io/v1alpha1
kind: MongoDB 
metadata:
  name: example
spec:
  replicas: 3 # 1 primary + 2 secondaries
  resourcesPreset: micro
  size: 10G1
  users:
    appuser:
      password: strongpassword
      roles:
      myapp:
        - readwrite
    analyst:
      password: readonlypass
      roles:
      myapp:
        - read
backup:
  enabled: false
  # resticPassword: <password>
  # s3Bucket: s3.example.org/mongo
  # schedule: "0 2 * * *”

ClickHouse

ReplicatedMergeTree Shards + Replicas ClickHouse Keeper

Column-oriented OLAP database, optimized for high-volume analytical queries. The architecture is based on two parameters: shards distribute data horizontally (more shards = more capacity and parallelism), replicas duplicate each shard for high availability.

ClickHouse Keeper (alternative to ZooKeeper, Raft protocol) coordinates replication between replicas. It requires an odd number of instances (3 recommended) for quorum.

OLAP only
ClickHouse is not suitable for frequent transactions (single UPDATE/DELETE). For transactional data, use PostgreSQL or MySQL.
Sharding and parallelism
SELECT queries run in parallel on all shards. For small volumes, 1 shard + 2 replicas is sufficient.
ClickHouse Keeper integrated
Automatically deployed with 3 instances by default. Manages Raft coordination between replicas on each shard.
Restic to S3 backups
Same model as MySQL - encrypted snapshots, configurable retention, Hikube-compatible S3 endpoint.

Production recommendation

replicas: 3 + quorum.minSyncReplicas: 1 for a good compromise between performance and durability.

yaml

apiVersion: apps.cozystack.io/v1alpha1
kind: ClickHouse 
metadata:
  name: example
spec:
  shards: 1 # Partitions horizontales
  replicas: 2 # Copies par shard → 2 pods
  resourcesPreset: small
  size: 10Gi
  clickhouseKeeper:
    enabled: true
    replicas: 3 # Toujours impair
    resourcesPreset: micro
    size: 1Gi
  users:
   user1:
     password: strongpassword
   analyst:
     readonly: true
     password: readonlypass

Why managed

Less ops, more business code

Maintaining a database in production means managing version updates, monitoring replication, configuring backups, testing restoration procedures and intervening at 3 a.m. when a primary goes down. This is not added value, it's infrastructure.

With Hikube, this burden disappears. You declare what you want - type of database, number of replicas, size, users - and the operator automatically provisions, replicates, fails over and backs up. Your teams focus on queries, schema and application performance, not infrastructure.

Databases are hosted in Switzerland, in the same datacenter as your Kubernetes Hikube clusters. Latency between your application and your database is minimal, and your data never leaves Europe.

Multi-tenant SaaS application

Each client has an isolated schema in the same PostgreSQL instance. ACID transactions, integrity constraints, complex joins. The secondary replica absorbs reporting requests without impacting the primary.

replicas: 3 - quorum: 1 - WAL backup

CMS and e-commerce platform

WordPress, Magento, PrestaShop. All these applications are designed for MariaDB. Migration from self-hosted MariaDB without code changes. External LoadBalancer provides direct access from administration tools.

replicas: 3 - external: true - Restic backup

Session cache and rate limiting

Storage of user sessions in a high-frequency API. Sub-millisecond latency, automatic key expiration (TTL), atomic counters for rate limiting. The Sentinel guarantees continuity even if the master falls.

replicas: 3 - authEnabled: true - storageClass: local

Product catalog and REST API

E-commerce catalog with variable attributes according to category (clothing, electronics, food). MongoDB's flexible schema avoids table migrations for each new product type. Indexing on any nested field...

replicas: 3 - Replica Set - Restic backup

Real-time analytics on application logs

Handle billions of events (logs, metrics, clicks). Aggregated queries run in seconds, even on multi-terabyte tables, thanks to column storage and sharding. Ideal for BI dashboards and real-time alerts.

shards: 2 - replicas: 2 - Keeper: 3

Complete stacks for ML applications

PostgreSQL for structured data (users, jobs), Redis for the ML job queue and results cache, MongoDB for model artifacts and metadata (variable structure), ClickHouse for real-time inference metrics.

PG + Redis + Mongo + ClickHouse

Common features

What all services share

Every database managed on Hikube exhibits the same fundamental mechanisms, regardless of the technology chosen.

Declarative deployment via kubectl
A YAML manifest, a kubectl apply. The operator automatically provision and maintain the cluster.
Credentials auto-generated in a Secret
Each service generates a Kubernetes Secret <service>-<name>-credentials containing passwords. No manual configuration of access.
Integrated S3 backups
PostgreSQL uses WAL archiving + CloudNativePG. MariaDB and ClickHouse use Restic. All to any compatible S3 endpoint, including Hikube buckets.
Resource presets or explicit configuration
resourcesPreset (nano to 2xlarge) for quick start-up. resources.cpu and resources.memory for production environments. Both are mutually exclusive.

nano

250m

128 Mi

micro

500m

256 Mi

small

1 CPU

512 mi

medium

1 GPU

1 Gi

large

2 GPUS

2 Gi

xlarge

4 GPUS

4 Gi

2xwide

8 GPUS

8 Gi

Yes, this is the recommended use case. Create a Hikube bucket, retrieve the credentials from the generated Secret, and enter them in the backup section of your manifest, so that your backups remain on the same infrastructure, in Switzerland.

resourcesPreset applies a predefined profile (nano, micro, small...). This is the easiest way to get started. If you define resources.cpu and resources.memory explicitly, the preset is ignored entirely. The two are mutually exclusive - don't combine them in the same manifest.

No. ClickHouse is an OLAP engine optimized for analytical queries - aggregations, column scans on large volumes. It is not suited to frequent transactional operations (unitaryUPDATE / DELETE, ACID transactions). For transactional queries, use PostgreSQL or MySQL on Hikube.

Yes, the MySQL service on Hikube is based on MariaDB, an open-source fork of MySQL that is fully compatible with the MySQL protocol, syntax and clients. Your applications, drivers and ORMs will work without modification.

Minimum 3. Redis Sentinel needs a quorum - a majority of Sentinels (2 out of 3) must agree to decide on a failover. With replicas: 3, you get 3 Redis pods and 3 Sentinel pods, guaranteeing quorum even if one Sentinel is unavailable.

PostgreSQL, MariaDB, Redis, MongoDB, ClickHouse.
kubectlapply - that's it.

5 DBS

Native HA

S3 backup

0 config

The right engine for every application

Each database in detail

Postgres

Production recommendation

MariaDB

External exposure

Redis

StorageClass and replication

MongoDB

Production recommendation

ClickHouse

Production recommendation

Less ops, more business code

Automatic failover without intervention

Declarative scaling

Testable, scheduled backups

Kubernetes-native credentials

Which base for which need?

Multi-tenant SaaS application

CMS and e-commerce platform

Session cache and rate limiting

Product catalog and REST API

Real-time analytics on application logs

Complete stacks for ML applications

What all services share

Questions about managed databases

Can I save to Hikube S3 buckets?

What's the difference between resourcesPreset and resources?

Is ClickHouse suitable for my transactional requests?

Is the MySQL service compatible with my existing MySQL applications?

How many Redis replicas are needed for automatic failover?

PostgreSQL, MariaDB, Redis, MongoDB, ClickHouse. kubectlapply - that's it.

5 DBS

Native HA

S3 backup

0 config

The right engine for every application

Each database in detail

Postgres

Production recommendation

MariaDB

External exposure

Redis

StorageClass and replication

MongoDB

Production recommendation

ClickHouse

Production recommendation

Less ops, more business code

Automatic failover without intervention

Declarative scaling

Testable, scheduled backups

Kubernetes-native credentials

Which base for which need?

Multi-tenant SaaS application

CMS and e-commerce platform

Session cache and rate limiting

Product catalog and REST API

Real-time analytics on application logs

Complete stacks for ML applications

What all services share

Questions about managed databases

Can I save to Hikube S3 buckets?

What's the difference between resourcesPreset and resources?

Is ClickHouse suitable for my transactional requests?

Is the MySQL service compatible with my existing MySQL applications?

How many Redis replicas are needed for automatic failover?

PostgreSQL, MariaDB, Redis, MongoDB, ClickHouse.
kubectlapply - that's it.