Databases

Databases manages the MariaDB and PostgreSQL databases and the Valkey key-value stores for your applications.

Creating one provisions three things at once, on the server you choose:

• the store itself
• a user with the same name
• full read and write access between the two

There's no separate "database users" page to fill in afterwards.

Valkey is a different kind of store

Most of this page is about MariaDB and PostgreSQL, where you keep permanent data. Valkey is an in-memory cache whose data is temporary by design, so it has its own section, Key-value store (Valkey), without the parts that only apply to a SQL database: dumps, restores, extensions, and scheduled backups.

SQLite isn't managed here

A SQLite database is one file with no server and no credentials, so there's nothing to provision. You open one from the file manager, which still gives you a browser tool for it. See SQLite databases.

Two properties shape everything else here:

• A database isn't reachable from the Internet. Your applications reach it over the server's internal network; you reach it through the built-in browser tools or an SSH tunnel.
• The panel keeps the credentials. The database's page shows the password whenever you need it, and the browser tools sign you in automatically. You never type it.

Create a database

The form asks for a Database Server and a Database Name. Password and Note are optional.

Your provider decides which servers you see

The panel supports MariaDB, PostgreSQL, and Valkey; your provider decides which engines, versions, and how many of each appear in the Database Server list, and the same form creates all of them. If the engine you need isn't offered, ask your provider; it's not a limit of the panel.

Naming rules:

• Lowercase letters, digits, and underscores.
• At most 20 characters.
• The panel prefixes your account username. If your account is acme and you name the database shop, the real database name is acme_shop, and so is the username.

A database name can be publicly visible

Names show up in error messages, connection strings, and process lists. Choose one that doesn't tell a reader what the database belongs to.

Password rules:

• Leave the field empty and the panel generates a strong password.
• If you set your own, use only letters and numbers. That way it never needs quoting in a shell command, a connection URL, or a configuration file.
• You can change it later from the database's Edit page, with immediate effect.

The character encoding of a SQL database is fixed to a modern default, utf8mb4 on MariaDB and UTF8 on PostgreSQL, and isn't a choice in the form. Valkey stores raw bytes and has no encoding setting.

Connect from your application

The database's page shows the full Connection Parameters: hostname, port, database name, username, and password, each one copyable, and configuration to paste into the common environments: a command-line client, PHP with PDO, Laravel, Symfony, Drupal, WordPress, Python, Node.js, Java, Go, and Ruby.

The hostname looks like acme_shop.db.internal and resolves only inside the server, by design. Your app servers, containers, websites, and cron jobs can use it; nobody outside can.

Connect from your own machine

Since the database isn't public, a desktop tool such as DBeaver, TablePlus, or DataGrip connects through an SSH tunnel. The database's page lists the exact SSH parameters and a ready-made command:

ssh -p PORT -L 3306:acme_shop.db.internal:3306 [email protected]

Copy the command from the page rather than retyping it

The SSH port isn't necessarily 22, and the command on the page already has the right one. The same goes for the connection strings, for a tool that asks for a port in its own dialog.

While the tunnel is open, your tool connects to 127.0.0.1 with the usual credentials. See SSH for SSH access in general.

For quick work, skip the tunnel

• Shell opens a browser terminal with the right client, mariadb or psql, already running and signed in to this database.
• phpMyAdmin (MariaDB) and Adminer (MariaDB, PostgreSQL, and Valkey) open in a new tab, already signed in through a short-lived, single-use ticket the panel creates for your session, so the password never appears in the URL or your browser.

Dumps and restores

Dumps, restores, and scheduled backups apply only to MariaDB and PostgreSQL. Valkey holds temporary data and isn't backed up. See Key-value store (Valkey).

Download Dump exports the database as a SQL file. You choose:

• what to include: Schema and Data, Schema Only, or Data Only
• a compression format: none, Gzip, Bzip2, XZ, or Zstd

The dump streams straight to your browser, so a large database needs no temporary space on the server.

Restore Database uploads and imports a .sql dump, plain or compressed, up to 2 GB. The progress output streams live to your browser.

A restore doesn't empty the database first

It imports into the database as it is. Restoring over live data is safest when the dump carries its own DROP TABLE and CREATE TABLE statements, as a dump from Download Dump does.

Errors from the import appear as they happen, not collected at the end.

Manual dumps aren't the only protection: scheduled backups cover every database. The database's page shows its backup schedule and last run.

PostgreSQL extensions

A PostgreSQL database's page lists its installed extensions. You can add more from the set your provider approved for self-service; a few are mandatory and can't be removed.

note

If the extension you need isn't offered, ask your provider to approve it. The list is a per-server policy, not a technical limit.

MariaDB has no equivalent, so this section only appears on a PostgreSQL database.

Key-value store (Valkey)

Valkey is an in-memory key-value store, compatible with Redis at the protocol level. There are no tables and no SQL; you set and get keys (strings, hashes, lists, sets, sorted sets, and streams) with the protocol every Redis client speaks.

Use it for what a relational database does badly: session storage, page and object caches, job queues, rate-limit counters, publish and subscribe, and locks.

Temporary by design

Your data isn't permanent, by design

• The store deletes a key that nothing reads or writes for 24 hours.
• When it's full, it removes the keys that have gone unused the longest to make space.
• There are no dumps, no restores, and no scheduled backups. They don't apply to a cache.

So treat every value as something that can disappear at any moment:

• Your application must keep working when a key is missing.
• Anything you can't lose, e.g. a payment, an invoice, or the only copy of a job, belongs in MariaDB or PostgreSQL.
• Give every key an explicit TTL. Don't depend on a key staying forever.

Connect to the store

The connection parameters look like a SQL database's, and the same two rules apply: the store is not reachable from the Internet, and the panel keeps the credentials.

Parameter	Notes
Hostname	acme_shop.db.internal. Resolves only inside the server: your app servers, containers, websites, and cron jobs can reach it; nobody outside can.
Username and password	The credentials are an ACL user, so authentication takes both a username and a password, unlike a bare Redis server that takes a password alone. Many clients expect the pair, and the database's page shows exact examples.
URL	A redis://username:password@hostname:port string you can copy, for a tool or framework that takes one DSN.

The page has copy-and-paste configuration for the common cases: valkey-cli, PHP with phpredis and with Predis, Symfony (cache, sessions, Messenger, and Lock), Laravel, and the WordPress Redis Object Cache plugin, each filled in with this store's real credentials.

From your own machine, use an SSH tunnel, exactly as with a SQL database:

ssh -L 6379:acme_shop.db.internal:6379 [email protected]

While the tunnel is open, point any Redis or Valkey client at 127.0.0.1:6379 with the same username and password.

For a quick look, Shell opens a browser terminal with valkey-cli already running and signed in to this store.

Look at keys in Adminer

Adminer opens the store already signed in, as for a SQL database. There's no phpMyAdmin for a key-value store.

Here Adminer is a key browser and a command console, not a full editor:

• Your keys appear in one table named data, with three columns: key, type, and value.
• Only a string key shows a value. A hash, list, set, sorted set, or stream shows its type and an empty value.
• To read or change those types, use the SQL command box. It runs any Redis or Valkey command, e.g. HGETALL, LRANGE, SMEMBERS.
• There's no expiry column. Read it with TTL yourkey.
• The DB switcher at the bottom of the page moves between the 16 numbered databases. The panel signs you in to database 0.

The command box runs everything, including FLUSHALL

It has the same power over your store as valkey-cli, with no confirmation step and no backup to restore from afterwards.

Live status

The page shows a Live Status panel with:

• whether the store is Running or Idle
• its memory limit and current use
• the number of connections and keys
• the time of its last activity

Idle is normal

The backend stops itself after a few minutes without connections and starts again, silently, when your application connects. An idle store hasn't lost your keys.

If the store shows as Unreachable, it may be restarting, or your provider turned it off for a while. Your data and credentials don't change.

Work inside the limits

Because keys expire and can be removed, a few framework integrations need care. The database's page has the details; in short:

• Caching works well. Use a plain Redis cache pool and set an expiry on each entry. Symfony's tag-aware cache adapter refuses to run on a store that removes keys, so use the ordinary cache.adapter.redis.
• Queues and locks are fine for work you can lose or run again, not for work that must not be lost or run twice. If the store removes a lock key, two processes can hold the "same" lock; if a queue sits idle, the store can delete it. Route a critical message to a permanent transport instead.

Delete a database

Deleting a database drops the database and its user on the server.

You can't undo this from the panel

For a SQL database, the data is recoverable only from a backup or a dump you downloaded earlier. A Valkey store has neither, so its keys are gone.

There's no limit on the number of databases. What matters is storage, and the Databases list shows each database's.