Skip to content
My account

9 database engines, 26 plans, one operating model. We handle provisioning, backups, encryption, monitoring and version upgrades — using the same procedure for every engine. Exactly where the line is drawn between your side and ours is explained right in the first section.

Configure databaseMigrate existing data

The default is the private endpoint in the vRack — the private network between your own servers — meaning no public address. TLS, the encryption of the connection, cannot be disabled; unencrypted connections are rejected.

Engines
9
relational, document, cache, analytics, search, streaming
Entry
€47.30$54.87
Grafana Essential S, monthly net
Largest plan
64 GB
RAM, ClickHouse Analytics L
Plans
26
across all engines

What we take over, what stays with you

A managed database takes operations off your hands, not data modelling. Ahead of any plans, these two columns show which part lies on which side.

Operations

ENTRONYX CLOUD takes over

Included in every plan, without additional agreement.

Delivery
Node, operating system, engine version and network connection. You get a connection string, not a machine to set up.
Backup
Once a day the full dataset, in between continuously the journal, i.e. the log of every single change — encrypted and in a different region to the instance.
Failover
From two nodes, a sentinel monitors the primary role. If it fails, a replica takes over, typically in under 30 seconds.
Encryption
AES-256 for stored data, TLS 1.3 for every transmission. A connection attempt without TLS is rejected, not silently permitted.
Version upgrades
Minor versions in the maintenance window, major versions after pre-checking. We announce the dates.
Metrics
Connections, buffer hit ratio, replication lag and lock wait times are available at a Prometheus endpoint — the common query format for monitoring tools.
Application

You keep

Everything that depends on your application — and therefore nobody can decide for you.

Schema and queries
Tables, indexes, execution plans. We see the slow query in the log — but we do not rewrite it.
The right size
Which plan, how many nodes, how many read replicas. There is no automatic scaling that silently increases the invoice.
Reconnection
After a failover, the connection string has the same name, but a different address. Your application must be able to reconnect.
Connection management
How many connections your application pool keeps open simultaneously. The limit of the instance is a limit, not a target.
Access rights
Roles, passwords and the allowlist of the public endpoint. An empty list means blocked, not open.
Archiving
The included retention protects against errors of the last few weeks, not against retention obligations over years.

How much is lost in the worst case

The recovery point is the distance between the last backable state and the failure. It does not depend on the plan, but on the engine.

3 of the 9 services maintain a continuous journal between two full backups and therefore restore to a freely chosen second: PostgreSQL, MySQL, MongoDB. The loss there is limited to the write operations that the journal had not yet recorded at the time of the failure.

The remaining 6 services back up in snapshots. Without a journal, the worst case is a full day — 1,440 minutes between two full backups. If you cannot bear this, you belong on an engine with a journal or need a second write path in the application.

How far back — the tiers from the configurator

Retention does not determine how accurately you hit, but how far back you can go. Both together provide the protection: the accuracy from the journal, the reach from this tier.

Snapshots (7 days)
€9.00$10.44
Daily snapshots, 7 recovery points, stored in the ENTRONYX network.
Managed backup (30 days)
€29.00$33.64
Daily incremental backup, 30 points, geo-redundant in a second region.
Vault backup (365 days)
€79.00$91.64
Immutable storage with WORM lock for compliance requirements.
Two identical server bays next to each other, one with a green, one with a blue status light.

Replica · Failover under 30 s

A replica is not a backup. It keeps the same state as the primary node — including the accidentally deleted one. Against an operating error, only the rollback to an earlier point in time helps.

Row of drive bays in a storage cabinet, recessed grips in grazing light.

Storage · Backup in second region

The database runs on local NVMe drives — fast SSDs directly attached to the node. The backup lies alongside in Object Storage, always in a different region. A location failure at ENTRONYX CLOUD therefore never hits both at the same time.

Opened 2U server chassis from diagonally above on the workbench: heatsink with copper base over the socket, populated and locked memory banks, fan wall, power supplies with IEC connector at the back, drive bays at the front.

Nodes · ECC memory, local NVMe drives

Every database node runs on a server with registered ECC memory, which detects and corrects flipped bits before they get into a table, and with local NVMe drives. Replicas are always located in separate fire compartments — a failover therefore still finds a node even if an entire room fails.

4 words that are assumed further down

Replica
a continuous second copy of the same database on another node
Failover
the switch of the write role to a replica when the primary node fails
Point-in-time recovery
the rollback to a freely chosen second instead of just to the last backup
Connection limit
how many clients may be connected simultaneously; in English Connection Limit

First the data model, then the plan

The wrong engine cannot be cured with more memory. This overview categorises the six services by what they store and how they are accessed. Size comes in the next section.

Overview of the six database services with data model, access type, typical load, major versions and starting price
ServiceData modelAccessTypical loadVersionsfrom
PostgreSQLrelational + JSONBSQLOLTP, mixed171615€54.46$63.17
MySQLrelationalSQLOLTP, read-dominated8.48.0€54.46$63.17
ValkeyKey-value in RAMRESP commandsCache, sessions8.07.2€107.75$124.99
MongoDBDocumentsMQL, aggregationvariable schemas8.07.0€243.97$283.01
ClickHousespaltenorientiertSQLAnalytics, logs25.324.8€189.00$219.24
Apache Kafkadistributed logProducer/Consumerevent streams3.93.8€353.03$409.51

From data model to machine

26 plans across six engines, from €47.30$54.87 to €1,666.59$1,933.24 per month. The choice depends on three factors: the working set, the dataset, and whether an outage can last minutes or seconds.

All plans of all engines with vCPU, memory, storage, node count and monthly price, net
EnginePlanvCPURAMStorageNodesMonth
PostgreSQLEssential S24 GB80 GB1no failover€54.46$63.17
PostgreSQLBusiness M27 GB160 GB2€277.25$321.61
PostgreSQLBusiness L415 GB320 GB2€554.36$643.06
PostgreSQLEnterprise XL830 GB640 GB3€1,666.59$1,933.24
MySQLEssential S24 GB80 GB1no failover€54.46$63.17
MySQLBusiness M415 GB320 GB2€554.36$643.06
MySQLEnterprise L830 GB640 GB3€1,666.59$1,933.24
ValkeyCache S28 GBRAM only1no failover€107.75$124.99
ValkeyCache M416 GBRAM only2€481.36$558.38
ValkeyCache L832 GBRAM only2€962.87$1,116.93
MongoDBBusiness S28 GB40 GB3€243.97$283.01
MongoDBBusiness M416 GB80 GB3€483.77$561.17
MongoDBBusiness L832 GB160 GB3€941.92$1,092.63
ClickHouseAnalytics M832 GB500 GB1no failover€189.00$219.24
ClickHouseAnalytics L1664 GB2.0 TB3€549.00$636.84
Apache KafkaStream S24 GB480 GB3€353.03$409.51
Apache KafkaStream M415 GB1.9 TB3€1,329.99$1,542.79
OpenSearchEssential S24 GB40 GB1no failover€59.42$68.93
OpenSearchBusiness M27 GB240 GB3€386.10$447.88
OpenSearchBusiness L415 GB480 GB3€772.19$895.74
OpenSearchEnterprise XL415 GB960 GB6€1,564.10$1,814.36
Apache CassandraEssential S24 GB40 GB1no failover€96.80$112.29
Apache CassandraBusiness M415 GB480 GB3€867.90$1,006.76
Apache CassandraBusiness L830 GB960 GB3€1,597.17$1,852.72
GrafanaEssential S24 GBRAM only1no failover€47.30$54.87
GrafanaEssential M27 GBRAM only1no failover€95.70$111.01

The node count is not a performance metric: a second node does not double the throughput, but shortens the outage. The largest plan features 64 GB memory — enough to keep the working set of most applications entirely in memory.

The relational default

Unless the requirements explicitly dictate otherwise, this is the right choice: fixed schemas, real transactions, JSONB for everything that doesn't fit into columns — and extensions that make a second database alongside it redundant.

The relational default

PostgreSQL

Managed PostgreSQL with automatic failover, point-in-time recovery and pgvector for embeddings.

Versions171615

from€54.46$63.17per month, net

Choose it for

  • Transactional core systems with foreign keys, check constraints and real transactions
  • Mixed workloads: relational tables alongside JSONB documents in the same query
  • Similarity search over embeddings with pgvector, without a second database alongside
  • Geospatial data with PostGIS, time series with native range partitioning

Do not choose it for

  • Analytical queries over billions of rows — ClickHouse is orders of magnitude faster for this
  • As a high-throughput queue; SKIP LOCKED goes a long way, but not as far as Kafka
  • Pure session or page cache, for which memory is sufficient
Extensions
pgvector, PostGIS, pg_cron, pg_partman
Connection pooler
upstream, transaction mode
Read replicas
up to 5, also cross-region
Recovery point
to the second (PITR)
Plans for PostgreSQL: vCPU, memory, storage, number of nodes and monthly price
PlanvCPURAMStorageNodesMonth
Essential S24 GB80 GB1no failover€54.46$63.17
Business M27 GB160 GB2€277.25$321.61
Business L415 GB320 GB2€554.36$643.06
Enterprise XL830 GB640 GB3€1,666.59$1,933.24

MySQL, MongoDB and ClickHouse in detail

Three services that do not need their own section but get the same data sheet: available major versions, plans with specifications and price, as well as an honest distinction — what they were built for and what they expressly are not.

Relational

Fixed schema, foreign keys and transactions — here in the version for legacy applications that speak MySQL and should continue to do so.

For established applications

MySQL

Managed MySQL with InnoDB cluster, read replicas and automatic backups.

Versions8.48.0

from€54.46$63.17per month, net

Choose it for

  • Existing applications from the PHP, WordPress and Magento ecosystem without porting effort
  • Read-heavy workloads that scale horizontally via replicas
  • InnoDB cluster with group replication and automatic primary election

Do not choose it for

  • Complex analytical queries with window functions over large datasets
  • Applications built on PostgreSQL extensions like pgvector or PostGIS
  • New projects without MySQL dependency — PostgreSQL offers more there for the same price
Character set
utf8mb4, collation utf8mb4_0900_ai_ci
Replication
GTID-based, semi-synchronous
Journal
Binlog, ROW format, 7 days
Recovery point
to the second (PITR)
Plans for MySQL: vCPU, memory, storage, number of nodes and monthly price
PlanvCPURAMStorageNodesMonth
Essential S24 GB80 GB1no failover€54.46$63.17
Business M415 GB320 GB2€554.36$643.06
Enterprise L830 GB640 GB3€1,666.59$1,933.24

Schemaless

Structure per record instead of per table. For data where fields can differ between two entries.

When the schema changes

MongoDB

Document database with replica set, aggregation pipeline and Atlas-compatible driver API.

Versions8.07.0

from€243.97$283.01per month, net

Choose it for

  • Catalogue and product data with highly variable fields per entry
  • Event and telemetry data whose structure changes over time
  • Applications that write aggregation pipelines instead of SQL

Do not choose it for

  • Highly connected models with many relationships — $lookup is not a JOIN
  • Reports over the entire dataset; the column-oriented storage is missing for this
  • Accounting consistency across many documents; transactions exist, but they are expensive
Topology
Replica Set with three nodes
Driver API
compatible with official drivers
Recovery
Oplog-based, accurate to the second
Indexes
compound, text, geo, TTL
Plans for MongoDB: vCPU, memory, storage, number of nodes and monthly price
PlanvCPURAMStorageNodesMonth
Business S28 GB40 GB3€243.97$283.01
Business M416 GB80 GB3€483.77$561.17
Business L832 GB160 GB3€941.92$1,092.63

Analytics

Not built for the individual record, but for throughput across billions of them.

Sub-second analytics

ClickHouse

Column-oriented analytics database for billions of rows with sub-second response times.

Versions25.324.8

from€189.00$219.24per month, net

Choose it for

  • Queries across billions of rows with sub-second response times
  • Log, metric and clickstream data with high compression
  • Materialised views that pre-aggregate on write

Do not choose it for

  • Transactional workloads with individual updates and deletions per row
  • Very high number of concurrent point queries — the optimiser is built for throughput, not concurrency
  • Referential integrity; foreign keys do not exist
Table engine
MergeTree family, default ReplicatedMergeTree
Compression
ZSTD, typically factor 8 to 12
Interfaces
HTTP, native protocol, MySQL port
Ingestion
Kafka engine for direct ingestion
Plans for ClickHouse: vCPU, memory, storage, number of nodes and monthly price
PlanvCPURAMStorageNodesMonth
Analytics M832 GB500 GB1no failover€189.00$219.24
Analytics L1664 GB2.0 TB3€549.00$636.84

Memory with network connection

Valkey is the open continuation of Redis: the same protocol, the same drivers, the same data structures — under a licence that explicitly allows it to be run as a managed service. Existing Redis clients connect without modification.

Choose it for

Versions8.07.2
  • Session management, object cache, rate limiting and distributed locks
  • Publish and subscribe as well as lightweight queues via streams
  • Leaderboards and counters with sorted sets at very high request rates

Do not choose it for

  • Primary storage of data whose loss is unacceptable
  • Data volumes larger than the memory of the plan
  • Queries over relationships — there are no joins and no indexes over values
Persistence
AOF every second, RDB hourly
No block storage
Dataset must fit into RAM
Cluster mode
from three nodes, 16,384 slots
Protocol
RESP3, Redis driver compatible

Memory classes

There is no block storage to add: the memory of the plan is the capacity. If the dataset does not fit, the plan is not too small, but the wrong engine was chosen.

Valkey storage classes. The memory is also the usable capacity — the “Storage” column is not missing here, it does not exist.
PlanvCPUMemoryNodesTypical useMonth
Cache S28 GB1no failoverSessions and object cache of a single application€107.75$124.99
Cache M416 GB2Shared cache of multiple services, rate limiting, locks€481.36$558.38
Cache L832 GB2Leaderboards and counters with very high request rates€962.87$1,116.93

Persistence mode

Two methods run simultaneously. The append-only file (AOF) logs every modifying command and is forced to the drive once per second. The snapshot (RDB) writes a complete image of the memory every hour.

When a node restarts, it reads from the append-only file again — the loss is then at most the last second. During a recovery from a backup, however, the reference point is the last snapshot, i.e. up to an hour. This is not a configuration error, but the price for an in-memory store not keeping a transaction log.

The practical rule from this: everything Valkey contains must be rebuildable from another source. If this is not the case, the data belongs in PostgreSQL and only its copy here.

How it differs from Kafka

Both have streams and consumer groups, and that is exactly why they are confused. The difference is not in the interface, but in where the data is stored and for how long.

Valkey Streams and Apache Kafka in comparison — storage, retention, distribution and operational effort
FeatureValkey StreamsApache Kafka
Storagein memoryon disk, included in the plan
Retentionlimited via MAXLEN, otherwise memory usage growsby time or size, configurable per topic
Rewindingto the oldest remaining entryto the beginning of the retention period, as often as required
DistributionCluster mode from three nodes, 16,384 slotsPartitions per topic, leader per partition
Schemano registry, content is the application's responsibilitySchema registry included (Avro, Protobuf, JSON Schema)
Operational effortone connection string, no topologytopics, partitions, consumer groups to plan
Starting price per month€107.75$124.99€353.03$409.51
Upper limit of data volume32 GB memory1.9 TB memory in the largest plan

Kafka: what happened, not what currently applies

A distributed log instead of a table. Every entry remains until retention ends — and every consumer reads it at their own pace. From €353.03$409.51 per month, always with 3 nodes, because a single broker does not secure a log.

Events instead of states

Apache Kafka

Managed event streaming with KRaft mode, schema registry and Connect runtime.

Versions3.93.8

from€353.03$409.51per month, net

Choose it for

  • Decoupling of services that do not need to be available at the same time
  • Change data capture from databases via Debezium and the Connect runtime
  • Repeatable processing: consumers rewind without loading the source

Do not choose it for

  • Request-and-response patterns; Kafka has no return channels
  • Queries on content — there is no index, only offsets and partitions
  • Small systems with few events per second; the operational effort is not worth it there
Operating mode
KRaft, without ZooKeeper
Schema registry
included, Avro, Protobuf, JSON Schema
Retention
by time or size, per topic
Encryption
TLS and SASL/SCRAM enforced
Plans for Apache Kafka: vCPU, memory, storage, number of nodes and monthly price
PlanvCPURAMStorageNodesMonth
Stream S24 GB480 GB3€353.03$409.51
Stream M415 GB1.9 TB3€1,329.99$1,542.79

What applies to every engine

Operational characteristics differ less between services than the data models. Where there are differences, they are in the table — not in the small print. Backup and recovery are in their own section below.

Automatic failover

In multi-node plans, a sentinel monitors the primary role. If it fails, a replica takes over; the switchover typically takes under 30 seconds. The connection string points to a name, not an address — your application only needs reconnection logic.

Encryption

Data at rest is AES-256 encrypted on NVMe, backups are additionally encrypted in Object Storage. In transit, TLS 1.3 with certificate validation applies; a connection attempt without TLS is rejected, not silently allowed.

Private network connection

Each instance gets an endpoint in the vRack 1 Gbit/s and no public address by default. If you need external access, you enable the public endpoint and provide an allowlist — empty means blocked, not open.

Metrics and logs

A Prometheus-compatible endpoint provides connections, buffer hit ratio, replication lag and lock wait times. Slow queries end up in the log and in the console, with an execution plan.

Operational characteristics per engine — where they differ
FeaturePostgreSQLMySQLValkeyMongoDBClickHouseApache KafkaOpenSearchApache CassandraGrafana
Failoverfrom two nodesPatroni, < 30 sGroup replication, < 30 sSentinel or cluster modeReplica set, election in < 15 sReplica takes over shardPartition leader switches automatically
Read replicasup to 5, cross-regionup to 5in cluster modein replica setvia shard replicasvia consumer groups
Storage in planup to 640 GBup to 640 GBRAM onlyup to 160 GBup to 2.0 TBup to 1.9 TBup to 960 GBup to 960 GBRAM only
Major version upgradein maintenance window, with pre-checkin maintenance window, with pre-checkrolling, without downtimerolling, without downtimerolling, without downtimerolling, without downtime
Connection limitGuideline 4 × vCPU + 100Pooler upstreamPooler upstream10,000 concurrentDriver pool per applicationdesigned for throughput, not concurrencyunlimited, partition count is the limit
Row of locked storage cassettes on a shelf, one of them pulled halfway out.

ENTRONYX CLOUD performs a full backup once a day and writes the journal in between. Every month, a sample is actually restored — a backup that has never been restored is a guess.

Backup · daily, testing monthly

Daily full backup, journal in between

A backup that no one has restored is a guess. That is why recovery runs here not only in an emergency, but as a monthly random sample — and always into a new instance, never over the running one.

  1. 01

    Full backup

    daily

    Once a day, the complete dataset is backed up and stored encrypted in Object Storage — always in a different region than the instance itself.

  2. 02

    Journal

    continuous

    Between two full backups, the transaction journal runs continuously. It closes the gap between the last full image and the point in time you select later.

  3. 03

    Retention

    14 days, up to 365 on request

    Fourteen days are included in every plan. For retention requirements, we extend this up to 365 days; the additionally used storage is billed.

  4. 04

    Recovery

    into a new instance

    You choose a point in time, we create a second instance from it. The running one remains untouched — comparing both states is thus part of the process and not its risk.

  5. 05

    Validation

    monthly

    Every month, a random sample is actually restored and checked against the source. Anything noticed during this is an operational process and not a discovery in an emergency.

Recovery point and process per engine
EngineRecovery pointMethod
PostgreSQLper secondBase backup and continuous WAL journal
MySQLper secondFull backup and binlog in ROW format, 7 days
Valkeylast snapshotRDB hourly, append-only file per second
MongoDBper secondFull backup and oplog
ClickHouselast backupFull backup per partition
Apache KafkaRetention instead of recoveryEvents remain readable in the topic

How an instance becomes accessible

A managed database is only managed if the route to it is also defined. The default is therefore: private, encrypted, with separate roles — and none of this can be switched off accidentally.

Each instance receives a name in the internal DNS and an endpoint in the vRack 1 Gbit/s — no public A record, no accessible address on the internet. If you need to access it from the outside, you must explicitly enable the public endpoint and provide an allowlist. An empty list means blocked, not open.

Private network bandwidths and their monthly surcharge, net
Private networkUse casesSurcharge
vRack 1 Gbit/sIsolated Layer 2 network across all locations.included
vRack 10 Gbit/sFor storage replication and database clusters.€39.00$45.24
vRack 25 Gbit/sDedicated fabric for HPC and hypervisor clusters.€119.00$138.04
vRack 50 Gbit/sFor distributed storage pools whose write path runs over the private network.€219.83$255.00
vRack 100 Gbit/sHighest expansion stage for clusters with synchronous replication between fire zones.€421.49$488.93
Connect, recover, replicate
# Get connection string — TLS is mandatory, not an option
entronyx db uri shop-pg --role app
# postgresql://app:…@shop-pg.fra1.db.entronyx.internal:5432/app?sslmode=verify-full
 
# Recovery to a point in time within the retention
entronyx db restore shop-pg \
  --point-in-time "2026-08-27T21:14:05Z" \
  --target shop-pg-restore
 
# Attach read replica in a second region
entronyx db replica create shop-pg --region hel1 --plan pg-m
sslmode=verify-full is the default. The root certificate is included in every image under /etc/ssl/certs/entronyx-db.pem and is updated via the package repository.

Three roles per instance

admin
Creates databases, schemas and other roles. Belongs in the deployment run, not in the application.
app
Read and write in exactly one database. This is the role that is in your connection string.
readonly
Read only, against a replica by default. For reports, exports and analysis tools.

Each role has its own password, which can be renewed individually. An application that connects with admin is a finding, not an operating state.

Migrate existing databases

The path is the same for every engine: transfer completely once, then continuously catch up until the lag is zero, and only then switch over. A midnight dump is not a migration, it's a gamble.

  1. 01

    Inventory

    1 to 2 hours

    Size per table, used extensions, character set and collation, roles and permissions, number of concurrent connections, longest running query. Everything that is special on the source becomes visible here — not just during import.

  2. 02

    Choose target plan

    Working set counts

    Memory at least as large as the frequently read part of the data, storage about one and a half times the inventory, number of nodes according to failure requirements. You can upgrade later, but downgrading is not always possible.

  3. 03

    Initial transfer

    depending on data volume

    Dump or base backup, imported in parallel. Owners and permissions of the source are deliberately omitted and reassigned in the target — otherwise you drag along roles that do not exist here.

  4. 04

    Continuously catch up

    Hours to days

    Logical replication, GTID replication or change streams keep the target up to date while the source continues to work. In this phase, you already test the application against the target — read-only.

  5. 05

    Switchover

    Maintenance window, a few minutes

    Stop write access on the source, wait until the lag is zero, swap connection string, check sequences, enable write access. If you do not measure the lag, you lose records.

  6. 06

    Keep the way back open

    7 days

    The source remains unchanged for a week. This costs little and is the only reliable rollback plan there is for a migration.

PostgreSQL migration with logical replication
# 1. Create target instance, private endpoint in the vRack
entronyx db instance create shop-pg \
  --engine postgresql --version 17 --plan pg-m \
  --region fra1 --vrack prod --no-public-endpoint
 
# 2. Transfer schema and data, without owner and permissions of the source
pg_dump --no-owner --no-privileges --format=directory --jobs=4 \
  --dbname="$SOURCE_URL" --file=/tmp/dump
 
pg_restore --no-owner --jobs=4 \
  --dbname="$(entronyx db uri shop-pg --role admin)" /tmp/dump
 
# 3. Continuously catch up until the lag is zero
psql "$SOURCE_URL" -c "CREATE PUBLICATION migration FOR ALL TABLES;"
psql "$(entronyx db uri shop-pg)" -c \
  "CREATE SUBSCRIPTION migration CONNECTION '$SOURCE_URL' PUBLICATION migration;"
 
# 4. Measure lag — only switch over at 0 bytes
psql "$(entronyx db uri shop-pg)" -c \
  SELECT application_name,
          pg_wal_lsn_diff(sent_lsn, replay_lsn) AS lag_bytes
     FROM pg_stat_replication;"
 
# 5. Clean up after the switchover
psql "$(entronyx db uri shop-pg)" -c "DROP SUBSCRIPTION migration;"
For MySQL, step 3 is replaced by GTID-based replication, for MongoDB mongosync with change streams. The pattern remains identical.
Tools and realistic downtime per engine
EngineInitial transferContinuousOutage
PostgreSQLpg_dump / pg_basebackuplogical replication< 5 min
MySQLMySQL Shell, util.copyInstanceGTID replication< 5 min
ValkeyImport RDB fileREPLICAOF against the source< 1 min
MongoDBmongodump / mongorestoremongosync, Change Streams< 10 min
ClickHouseINSERT … SELECT via remoteSecure()lag per partitionminutes to hours
Apache KafkaMirrorMaker 2MirrorMaker 2 with offset translationwithout downtime

Provision database or migrate existing data

An instance is up in a few minutes, with a private endpoint, enforced TLS and continuous backups from the first minute. For migrating existing systems, there is a guide and, upon request, support from our technicians.

Configure databaseDiscuss migration
Engines
9
from
€47.30$54.87
Plans
26
Failover
< 30 s