Databases

PandaStack runs managed PostgreSQL and MySQL databases as a first-class resource alongside your projects. Every database is provisioned as a KubeBlocks Cluster inside PandaStack’s Kubernetes fleet by the data-plane worker (worker-v3), reached through a single TLS proxy, and managed entirely from the dashboard, CLI, or API — you never touch Kubernetes yourself.

Push code. It runs — with a database, if you want one. A database can be created standalone or linked to a project so your app ships with a data layer.

What you get

Managed PostgreSQL & MySQL — the platform provisions, configures, and operates the cluster. You get a connection string; the control plane owns the rest.
A TLS-terminating proxy — every database is served through *.db.pandastack.app so you connect over an encrypted channel from anywhere (public) or only from inside the platform network (private). See Connecting.
Auto-generated credentials — omit a password and PandaStack generates a strong 24-character one, AES-encrypted at rest and revealed only on demand to authorized users.
Instance tiers — from a free 0.25 vCPU / 0.5 GB / 1 GiB instance up to 8 vCPU / 16 GB dedicated tiers, changeable in both directions. See Tiers & scaling.
Automated backups + in-place restore — schedule backups with a retention count and restore a completed backup in place (paid). See Backups & restore.
Engine metrics — connections vs. max, queries per second, and cache hit ratio sourced from Managed Prometheus (paid). See Metrics.
High availability — a replicaset architecture (multi-zone, 3 replicas) on paid tiers; single-zone standalone on free.

Supported engines

Databases are container databases only (deploymentModel = container). PandaStack stores the engine name uppercase internally and surfaces it lowercase (postgresql, mysql) on the wire.

Engine	Provisionable	Versions accepted	Notes
PostgreSQL	Yes	`16.4.0`, `14.8.0`	Use `16.4.0` for new databases. `14.8.0` is deprecated for new databases and kept temporarily. PostgreSQL 17/18 require KubeBlocks ≥ 1.0 (the fleet runs 0.9.1) and are not yet offerable.
MySQL	Yes	`8.4.2`, `5.7.44`	`8.0.33` exists on-cluster but is excluded (it CrashLoopBackOffs).
MongoDB	No	—	Listed in the engine picker but deprecated / unprovisionable — no new provisions.

Versions are validated against a server-side allow-list. An arbitrary version string is rejected because the worker concatenates the engine and version into a cluster version reference with no other fallback — only the versions above resolve to a working cluster.

Public vs. private

Every database carries a visibility of public or private:

Public databases are reachable from the open internet through the *.db.pandastack.app proxy over TLS. Use these when your client runs outside PandaStack (your laptop, a CI runner, an external host).
Private databases are reachable only from within the platform network — typically your PandaStack container apps in the same organization.

The proxy and the exact username rules differ by engine (MySQL has a special connection rule). This is covered in full on the Connecting page.

Connection strings & credentials

Database detail responses always return publicUrl and privateUrl masked — the password segment is replaced with ********. The host, port, username, and database name are broken out under connectionDetails with passwordAvailable: true, but the password itself is never included in a normal response.

To get the real values, a role-gated Reveal / Copy action fetches the decrypted password and substitutes it back into the full connection URLs on demand. Passwords are AES-encrypted at rest (iv:cipher).

See Connecting for connection strings, driver examples, and the copy-with-real-password behavior.

Backups & metrics

Backups are read live by proxying to worker-v3, which has Kubernetes access (the API layer does not). If worker-v3 is unreachable, backup and metric endpoints return an explicit unavailable shape rather than fabricating data. See Backups & restore.
Engine metrics (connections, QPS, cache hit ratio) come from KubeBlocks Managed Prometheus over ranges of 1h / 24h / 7d / 30d and are a paid feature. A separate live pod snapshot (phase, CPU, memory, restarts) is also available. See Metrics.

Free tier & lifecycle

Each organization may have exactly one free-tier database. A free database provisions on a 0.25 vCPU / 0.5 GB / 1 GiB instance, is single-zone only, and follows an automatic lifecycle: it is created with a 30-day expiry, suspended at 30 days, and purged 14 days later. Upgrade to a paid tier at any time to keep it running with no expiry. Paid databases never expire. See Free-tier lifecycle.

Lifecycle & status

Creating a database writes the row (status: queued) plus a transactional outbox row (database.provision) in a single database transaction. A relay publishes the outbox to Google Pub/Sub, and worker-v3 applies the KubeBlocks Cluster CR. Only after the pod reaches Running does the worker populate publicUrl, privateUrl, and the proxy version.

The database status enum:

Status	Meaning
`queued`	Provision request accepted, waiting for the worker
`pending`	Worker is preparing the cluster
`deploying`	Cluster is being applied / coming up
`running`	Healthy and connectable
`updating`	A tier change or config change is in flight
`stopped`	Cluster stopped (e.g. suspended free tier)
`deleting`	Being torn down
`failed`	Provision or update failed

While a database is in a busy status (updating, deleting, deploying, queued, pending), other changes are rejected — only one change at a time is allowed per database.

Linking a database to a project

A database can be created standalone or linked to a project by passing a projectId at create time. Linking associates the database with a project so the two are managed together. See Create a database.

In this section

Create a database — engine, version, tier, visibility, architecture, credentials.
Connecting — the TLS proxy, connection strings, the MySQL username rule, driver examples.
Tiers & scaling — the instance-tier catalog and changing tier in both directions.
Backups & restore — automated and on-demand backups, in-place restore.
Metrics — engine metrics and the live pod snapshot.
Free-tier lifecycle — the 30-day expiry, suspend, and purge timeline.

Instance tiers and Plans & limits — how database tiers and connection limits fit into your plan.
Database API — the REST endpoints behind everything on these pages.