Managed databases

Engines and versions

A managed database runs in its own container next to your services, on the project's private network. HostStack provisions it, takes a backup every night, and injects its connection details into the services you link it to.

MySQL 5.7 is past its upstream end of life (October 2023). It is still offered, marked legacy in the create form — pick 8.4 unless something you run needs 5.7.

PostgreSQL can be created with the PostGIS or pgvector image, so CREATE EXTENSION postgis or CREATE EXTENSION vector works. You choose one or the other when you create the database — they use different base images.

Comparing HostStack PostgreSQL with Aiven, Neon, RDS and others? Read the 2026 buyer's guide to managed PostgreSQL in Europe, or the side-by-side pages for Aiven, Neon and DigitalOcean. Plans, HA and what is not supported yet are summarised on one page in Managed Postgres.

Plans

Every engine uses the same four sizes. The price includes the storage shown and nightly backups.

If you don't pick a plan, you get starter. The free tier includes one Starter PostgreSQL per user. See Billing for how usage is charged.

Create a database and link it to a service

1. Create the database

   In the dashboard, open Databases and click New Database. Choose the project, the engine, a version and a plan. Provisioning happens in the background. The database is ready to use once its status is available.

2. Link it to the service that uses it

   A link tells HostStack which service gets the database's connection details. You give each link an alias, which becomes the prefix of the injected variables. See the next section for the names.

3. Deploy the service

   A link takes effect on the service's next deploy. Trigger a deploy, and the container starts with DATABASE_URL (or REDIS_URL / MONGO_URL) set. You never copy a password by hand.

hoststack db create --project prj_... --name app-db --engine postgres --plan starter
# + app-db (db_...)

hoststack db link db_... --service svc_... --alias DATABASE
hoststack deploy trigger svc_...

import { HostStack } from '@hoststack.dev/sdk';

const hs = new HostStack({ apiKey: process.env.HOSTSTACK_API_KEY! });
const teamId = 1; // "Team ID" in the output of: hoststack whoami

const { database } = await hs.databases.create(teamId, {
  projectId: 12, // numeric project id
  name: 'app-db',
  engine: 'postgres',
  plan: 'starter',
});

// resourceId is the NUMERIC database id, not the db_... publicId.
await hs.serviceResourceLinks.create(teamId, 'svc_...', {
  resourceType: 'database',
  resourceId: database.id,
  alias: 'DATABASE',
});

await hs.deploys.trigger(teamId, 'svc_...'); // DATABASE_URL is injected on this deploy

Create a Postgres database called "app-db" in project prj_...,
link it to the service svc_... and redeploy the service
so it picks up DATABASE_URL.

Injected environment variables

On every deploy, each linked database adds six variables, prefixed with the link's alias:

<ALIAS>_URL

string

The full connection URL, password included.

<ALIAS>_HOST

string

The host name on the project's private network.

<ALIAS>_PORT

string

5432, 3306, 27017 or 6379, depending on the engine.

<ALIAS>_DATABASE

string

The database name. Empty for Redis.

<ALIAS>_USERNAME

string

The user name. Empty for Redis, which authenticates as default.

<ALIAS>_PASSWORD

string

The password.

An alias is uppercase letters, digits and underscores, starts with a letter, and is at most 48 characters. The dashboard suggests DATABASE, REDIS or MONGO (then DATABASE_2 and so on); the CLI defaults to the database's name in upper case.

The conventional names

On top of the prefixed variables, the first linked database of each kind also sets the name most frameworks already read:

• DATABASE_URL — PostgreSQL, MySQL or MariaDB
• REDIS_URL — Redis
• MONGO_URL — MongoDB

"First" means first by alias, alphabetically. A variable you set yourself with the same name always wins, and setting it to an empty value stops HostStack injecting it at all.

Reference a field in your own variables

To build a variable of your own from a linked database, write a template in its value. It is expanded at deploy time:

PGHOST=${{databases.DATABASE.host}}
PRISMA_URL=${{databases.DATABASE.url}}?connection_limit=5

The fields are url (or its synonym connectionString), host, port, database, username and password. A placeholder that doesn't resolve — a typo in the alias or the field — is left as it is rather than replaced with an empty string, so you can spot it in the container's environment.

Connect to a database

The database's Overview tab shows the connection URL, host, port, database name, user name and password, masked until you reveal them. Reading credentials needs the admin role on the team — and, through the API, a key with full access. The URLs look like this:

postgresql://user:password@host:5432/dbname
mysql://user:password@host:3306/dbname      # MySQL and MariaDB
mongodb://user:password@host:27017/dbname
redis://default:password@host:6379

From your own computer, hoststack db connect opens psql, mysql, mongosh or redis-cli with the credentials filled in. The client has to be installed locally, and the database must have external access turned on (below) to be reachable from outside HostStack.

hoststack db credentials db_...   # print the connection details
hoststack db connect db_...       # open an interactive client

PostgreSQL databases also get Query (one read-only statement at a time), Insights (the slowest queries, from pg_stat_statements) and Users tabs in the dashboard.

External access

A database is private by default: only services on the project's network can reach it. To connect from a laptop, a BI tool or another cloud, turn on external access in the External Connections card on the database's Overview tab, or from the CLI:

hoststack db external db_... --enable --allow 203.0.113.0/24 --allow 198.51.100.7/32
hoststack db external db_... --disable

• The database gets a stable public host and port, and a separate external connection URL. The internal address your services use doesn't change.
• TLS is enforced, not just offered: a client that tries to connect without TLS over the public port is rejected.
• The allowlist takes up to 50 IPv4 or IPv6 CIDR ranges. With an empty allowlist, any address can connect — over TLS and with the password.
• Turning it off makes the database project-private again.

Backups and restore

Every database is backed up nightly at 02:00 UTC with the engine's own dump tool (see the table at the top), compressed, and uploaded to off-site object storage. The last seven dumps are listed on the database's Backups tab.

• Back up now takes an extra backup on demand.
• Download gives you a copy of an off-site backup as a standard dump file, so you can restore it anywhere.
• hoststack db backups db_... lists the archives that actually reached off-site storage — the evidence that the nightly schedule ran.

Restore a backup

On the Backups tab, click Restore next to a backup and confirm. The restore overwrites the database's current contents with that backup. The database is unavailable for a few seconds while it runs, and anything written since the backup was taken is lost. The activity log records when the restore starts and when it completes or fails.

Change plan, storage or version

Plan

Change it in the dashboard or with hoststack db update db_... --plan standard. A standalone database is resized in place — the container's memory and CPU limits are raised or lowered without a restart. Moving down a plan keeps the storage you already have.

Storage

hoststack db update db_... --disk 40 raises the storage allowance, in whole GB up to 1024. Storage can grow but not shrink — to shrink, create a new database and move the data.

Engine version

PostgreSQL and Redis can be upgraded in place to a newer major version: hoststack db upgrade-version db_... --to 18, or the upgrade action on the database page. The data is dumped, a new container of the new version is started and the data restored into it, so expect a short interruption. Downgrades are refused, and so are databases over 1 GB and HA clusters. MySQL, MariaDB and MongoDB upgrades aren't supported yet.

High availability for PostgreSQL

On the standard and pro plans, PostgreSQL can run as a three-node Patroni cluster: one leader and two replicas, with every commit waiting for at least one replica to confirm it. HAProxy sits in front of the three, so the connection URL stays the same when the leader changes. HAProxy notices a new leader within about five seconds.

HA costs nothing extra — a standard database is €15/mo and a pro one €50/mo either way.

Turn it on

HA is in beta and enabled per team: ask support to enrol yours. Once it is on, new standard and pro PostgreSQL databases are created as clusters. An existing standalone database can be moved with Upgrade to HA in the database's More menu, or hoststack db upgrade-to-ha db_...:

1. The standalone database is switched to read-only.
2. It is dumped with pg_dump, the cluster is created, and the dump is restored into it with pg_restore.
3. Traffic moves to the cluster. The old container is kept, read-only, for 24 hours and then removed.

If any step fails, the standalone database is switched back to read-write and keeps serving.

Watch the cluster

An HA database gets a Cluster tab listing its current and retired members and its failover history; hoststack db cluster db_... prints the same. Every leader change is recorded in the activity log as database.failover.complete.

Limits

• All three members run in one region. An outage of the whole region takes the cluster offline — there is no cross-region replication yet.
• Upgrading an existing database is limited to 1 GB (pg_database_size), because the dump is moved in memory. Contact support for a larger move.
• PostGIS and pgvector are not available on HA clusters. A database created with either stays standalone.
• micro and starter databases are always single-node.

On a machine of your own

If your team has enrolled its own machine — a spare desktop, a home server, a VPS you already pay for — the create form offers it under Where it runs (or pass --machine to hoststack db create). Every engine works there. Three things differ, and HostStack enforces all three:

• It is reachable only from that machine. A project's network is local to its host, so linking the database to a service that runs anywhere else is refused — otherwise the deploy would come up healthy and fail on its first query.
• It is always single-node. High availability needs several machines that don't fail together, which one computer can't be.
• External access can't be turned on. The public address would point at HostStack's edge, not at your hardware.

Backups still run nightly and are uploaded to HostStack's off-site storage, so they survive the machine. If it is switched off at 02:00, the backup is taken shortly after it reconnects. See Own machines.

Troubleshooting

Connection refused

From a service: check that the service and the database are in the same project, and that the service has been deployed since you linked the database. From your own computer: turn on external access, make sure your IP is in the allowlist, and connect with TLS.

DATABASE_URL is missing

A link only applies on the next deploy — trigger one. If the service links more than one SQL database, DATABASE_URL points at the one whose alias sorts first; read the <ALIAS>_URL of the one you mean instead.

Too many connections

Your app is probably opening connections without closing them. Use a connection pool (pg.Pool in Node.js, SQLAlchemy's pool in Python) and keep it small — especially on micro and starter, which have little memory per connection.

Upgrade to HA is refused

The database must be PostgreSQL on standard or pro, available, under 1 GB, without PostGIS or pgvector, not on a machine of your own — and your team must be enrolled in the HA beta.

Next steps

• Environment variablesSet your own variables and secrets next to the injected ones.
• Persistent volumesDisks for files that must survive a deploy, such as uploads.
• Own machinesRun databases and services on hardware you already have.
• BillingHow databases, storage and usage appear on your invoice.