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.

TRY FOR FREE DOCUMENTATION

PostgreSQL

Relational

Streaming + Failover

Transactional applications, APIs, SaaS

MariaDB

Relational

Binlog + auto-failover

CMS, e-commerce, legacy applications

Redis

Key-value

Sentinel + auto-failover

Cache, sessions, queues

MongoDB

Document

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; replicas are kept in sync by streaming replication from the primary. On failure, a replica is automatically promoted with no manual intervention.

Replicas are spread across different data centres: with replicas: 3, you get 1 primary + 2 standbys on 3 sites.

WAL + PITR backups
WALs are continuously archived to S3. Restore to any point in time between two backups.
Declarative users and databases
Declare users, databases, admin and readonly roles in the manifest. Credentials 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
Set quorum.minSyncReplicas so a transaction is committed only after a replica confirms.

Production recommendation

replicas: 3 + quorum.minSyncReplicas: 1 for a good performance/durability trade-off.

yaml

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 spread across different datacentres.

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 a 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 run in the same cluster. Prefer connecting via the ClusterIP service to limit the exposure surface.

yaml

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. 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
At least 3 Sentinel pods for quorum (2/3 majority). Failover is triggered by consensus between Sentinels.
Authentification by default
authEnabled: true by default - auto-generated password. Disable only in isolated development.
RDB/AOF persistence
Data survives restarts. Configure the 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

kind: Redis
metadata:
  name: example
spec:
  replicas: 3 # 3 Redis + 3 Sentinel 
  resourcesPreset: nano
  size: 1Gi
  authEnabled: true # auto-generated password 
  external: false 


Bash
# Retrieve the password 
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 via oplog replication. If the primary fails, an automatic election designates a new primary.

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

Replica Set with automatic election
At least 3 members for quorum (1 primary + 2 secondaries). The primary is elected by majority vote on 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 for quorum (1 primary + 2 secondaries).

yaml

kind: MongoDB 
metadata:
  name: example
spec:
  replicas: 3 # 1 primary + 2 secondaries
  resourcesPreset: micro
  size: 10Gi
  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, optimised for analytical queries on large volumes. The architecture rests on two parameters: shards distribute data horizontally (more shards = more capacity and parallelism), replicas duplicate each shard for high availability.

ClickHouse Keeper (a ZooKeeper alternative, Raft protocol) coordinates replication; it needs an odd number of instances (3 recommended) for quorum.

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

Production recommendation

shards: 2 + replicas: 2 + Keeper: 3 for a good capacity/availability trade-off

yaml

kind: ClickHouse 
metadata:
  name: example
spec:
  shards: 1 # Horizontal partitions 
  replicas: 2 # Copies per shard → 2 pods
  resourcesPreset: small
  size: 10Gi
  clickhouseKeeper:
    enabled: true
    replicas: 3 # Always odd 
    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 handling version updates, monitoring replication, configuring backups, testing restore procedures and stepping in at 3 a.m. when a primary goes down. That isn't added value, it's infrastructure.

On Hikube, that burden disappears. You déclare what you want - database type, number of replicas, size, users - and the operator provisions, replicates, fails over and backs up automatically. Your teams focus on queries, schéma and application performance, not infrastructure.

Databases are hosted in Switzerland, in the same datacentre 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 queries without impacting the primary.

replicas: 3 - quorum: 1 - WAL backup

CMS and e-commerce platform

WordPress, Magento, PrestaShop. All these applications are built for MariaDB. Migration from a self-hosted MariaDB with no code changes. The external LoadBalancer gives direct access from administration tools.

replicas: 3 - external: true - Restic backup

Session cache and rate limiting

User sessions in a high-frequency API. Sub-millisecond latency, automatic key expiry (TTL), atomic counters for rate limiting. Sentinel guarantees continuity even if the master goes down.

replicas: 3 - authEnabled: true - storageClass: local

Product catalog and REST API

E-commerce catalog with attributes that vary by 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

Ingest 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

Full stacks for an ML application

PostgreSQL for structured data (users, jobs), Redis for the ML job queue and results cache, MongoDB for model artefacts 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 exposes the same fundamental mechanisms, whatever the technology chosen.

Declarative deployment via kubectl
1 YAML manifest, 1 kubectl apply. The operator provisions and maintains the cluster automatically.
Auto-generated credentials in a Secret
Each service generates a <service>-<name>-credentials Secret containing the passwords. No manual access configuration of.
Integrated S3 backups
PostgreSQL via WAL archiving + CloudNativePG. MariaDB and ClickHouse via Restic. To any compatible S3 endpoint, including Hikube buckets.
Resource presets or explicit config
resourcesPreset (nano to 2xlarge) to start quickly. 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 CPU

1 Gi

large

2 CPUs

2 Gi

xlarge

4 CPUs

4 Gi

2xwide

8 CPUs

8 Gi

Yes, that's the recommended use case. Create a Hikube bucket, retrieve the credentials from the generated Secret, and fill them into the backup section of your manifest. Your backups then stay in the same infrastructure, in Switzerland.

resourcesPreset applies a predefined profile (nano, micro, small...). This is the easiest way to get started. If you set 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 optimised for analytical queries, aggregations or column scans on large volumes. It is not suited to frequent transactional operations (unitaryUPDATE / DELETE, ACID transactions). For transactional queries, use PostgreSQL or MariaDB 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.

At least 3. Redis Sentinel needs a quorum: a majority of Sentinels (2 out of 3) must agree to trigger a failover. With replicas: 3, you get 3 Redis pods and 3 Sentinel pods, which guarantees 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 use case

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

Full stacks for an ML application

What all services share

Questions about managed databases

Can I back up to Hikube S3 buckets?

What's the difference between resourcesPreset and resources?

Is ClickHouse suitable for my transactional requests?

Is the MariaDB 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 use case

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

Full stacks for an ML application

What all services share

Questions about managed databases

Can I back up to Hikube S3 buckets?

What's the difference between resourcesPreset and resources?

Is ClickHouse suitable for my transactional requests?

Is the MariaDB 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.