MariaDB and Redis-compatible databases are here

Two new engines

Until today, every database we ran was PostgreSQL. From today you can also create two other kinds, in the same account, the same region and on the same servers:

• MariaDB (MySQL-compatible), for MySQL applications: content management systems, shops, frameworks built around MySQL-compatible databases, and teams who know them best. We run MariaDB 11.8, the current long-term support release. MySQL clients, drivers and most MySQL applications connect to it as they are.
• Redis-compatible (Valkey), a key-value store kept in memory, for caches, sessions, queues, rate limits and counters. We run Valkey 9, the open-source server that speaks the same protocol, so your Redis clients and commands work unchanged.

Both were built the way our PostgreSQL databases are: two servers in two sites on high-availability plans, automatic failover decided by the cluster rather than by either server alone, encrypted backups you can restore to any second of the last 7 days, and TLS on every connection. The rest of this article says what each one gives you and where they differ from PostgreSQL.

MariaDB (MySQL-compatible)

MariaDB plans have the same sizes as our PostgreSQL plans: Dev for development, single-node plans, and high-availability plans from Starter upwards (see pricing). On a high-availability plan the primary runs in one site and a replica in another site of the same region.

Replication and failover

Replication is semi-synchronous by default: a commit is acknowledged to your application only once the replica has received it, so a failover loses no acknowledged commit. If the replica stops acknowledging for 10 seconds, the primary carries on alone, and the replica does not take over until it has caught up again. If you would rather commit faster, switch the database to asynchronous replication on its page, without a restart; a failover can then lose the last commits the replica had not received.

When the primary's server fails, the replica takes over. In our failover tests, with a program writing the whole time, writes came back after about 10 to 12 seconds and no acknowledged commit was lost.

Backups and restore

A full backup runs every day, and the binary log, which records every change, is archived every 30 seconds. Both are encrypted with a key of the database's own. You can restore to any second of the last 7 days, into a new database; the latest point is about a minute behind now.

Connecting

The database page shows one connection string, in the form MySQL tools use:

mysql://u_<id>@<id>.db.electradb.com:<port>/app?ssl-mode=VERIFY_IDENTITY

TLS is required, with the server's name checked. The certificate is a public one, so the certificate authorities your system already trusts verify it. The user u_<id> has all privileges on the database app, which is where your tables go. The quickstart has examples for the mysql and mariadb clients, PyMySQL, mysqlclient, Node.js and Java.

Redis-compatible (Valkey)

Key-value plans are priced by the size of the dataset they hold, which the pricing page shows for each plan. That figure is 60% of the plan's memory; the rest is room for Valkey to take snapshots and rewrite its log without running out. There are Dev plans, single-node plans and high-availability plans with two members in two sites.

Replication and failover

Valkey has no synchronous replication, so we offer three modes and say plainly what each can lose:

• Asynchronous (the default): writes are acknowledged at once and copied right after. A failover can lose the last moment of writes.
• Bounded to 1 second or to 5 seconds: a failover loses at most about that much of acknowledged writes. While the replica is gone or further behind than that, writes are briefly refused, then continue unreplicated.

Failover is decided the same way as for PostgreSQL: a small keeper runs next to each member, the keeper of the primary holds a lease, and the quorum of our servers decides who holds it (see Constellations: the three servers behind every database), so two members never both take writes. In our tests a failover took about 10 to 13 seconds. MariaDB fails over through the same kind of keeper.

Memory and eviction

By default nothing is evicted: when the dataset reaches the plan's size, writes fail with an out-of-memory error, which is what you want for data you keep. For a cache, pick an eviction policy instead (least recently used, least frequently used, or shortest time to live), and Valkey removes keys to make room. You can change it on the database page at any time.

Backups and restore

The append-only file, Valkey's log of every write, is archived every 30 seconds, so you can restore to any second of the last 7 days. We also take a snapshot of the whole dataset once a day and keep the latest 7, and you can take one yourself, at most every 15 minutes. Restores create a new database. Everything is encrypted with the database's own key.

Connecting

rediss://u_<id>:<password>@<id>.db.electradb.com:<port>

rediss:// turns on TLS in most clients, verified against a public certificate. Log in as u_<id> with the password, which is shown once. The database page has examples for redis-cli, Python, Node.js, Jedis and Lettuce. High-availability plans also have a read-only connection string on a second port that reads from the replica.

How they differ from our PostgreSQL

Most things work the same across the three engines:

• The same kinds of plans, the same regions, the same database page, API and IP allowlist. A high-availability database changes plan in place; other plans change by restoring into a new database.
• The same storage guard: when a database reaches its plan's disk, it becomes read-only instead of filling up. Reads keep working, and so do the commands that free space (DELETE, DROP and TRUNCATE on MariaDB; DEL, UNLINK, EXPIRE and FLUSHDB on Valkey). See When your database is full.
• The same hostname for the life of the database, through failovers and plan changes.

And a few things differ:

• What a failover can lose. PostgreSQL's high-availability plans keep a synchronous standby by default. MariaDB's semi-synchronous default gives the same promise for acknowledged commits. Valkey's modes bound the loss but never reach zero.
• One address per connection string. mysql:// URLs and Redis clients take one host, so there is no multi-host connection string. High-availability databases show two extra names instead, <id>-primary and <id>-fallback, for clients you configure with a list of servers.
• Snapshots. Only key-value databases have them, as a second way to restore next to the 7-day point-in-time window that all three engines share.
• What fills up. A key-value database is limited first by memory, its dataset size; MariaDB and PostgreSQL by disk.

A database keeps its engine for life. To move data between engines, export it from one and load it into a new database of the other.

Getting started

1. Sign up, or sign in to your account.
2. Choose New database, then MariaDB or Redis-compatible.
3. Pick a region and a plan, and for high-availability plans the replication mode (and, for key-value, the eviction policy). You can change both later.
4. Copy the connection string and the password from the database page once it is live, and connect with the examples there (MariaDB's are also in the quickstart).

For example, once a key-value database is live, this checks the connection from your machine:

redis-cli --tls -u "rediss://u_<id>:<password>@<id>.db.electradb.com:<port>" PING

Questions about plans, limits and what each engine is suited for are answered in the FAQ and the guides, and the Terms say exactly what each engine's replication promises.

About the names

We use the names MariaDB and Valkey only to say which software we run, and "MySQL-compatible" and "Redis-compatible" only to say which clients and commands it works with. MariaDB and MySQL are trademarks of their owners, as are the other product names in this article, and we are not affiliated with or endorsed by them.