Skip to main content
Live. This area is documented as current, user-reliable behavior.

​
Goal

Create a database with the right expectations for placement, stable connectivity, access policy, recovery, and future transfers.

​
Prerequisites

  • An active account and available database capacity
  • A project if the database should be project-attached
  • A plan for private or public application access

​
Workflow

1
Choose whether the database belongs to a project or should remain standalone.
2
Choose an engine offered for the placement and an available size/storage option.
3
Choose Private, Restricted by IP, or Open to internet. For public access, choose Direct connection or StackShift tunnel.
4
Wait for provisioning and any public-access policy to become active before retrieving final connection information or starting a transfer.
5
Connect the application through the displayed stable endpoint and verify TLS and access policy.

​
Choose the ownership context

  • Project-attached: use when the database belongs to one application/project and should follow project access controls.
  • Standalone: use when the database belongs directly to your account and may serve more than one workload.
  • The context determines authorization and API route family; it does not change the hosted database engine.

​
Choose an engine and size

  • Pick an available PostgreSQL, MySQL, MariaDB, ClickHouse, or Redis version for the selected placement.
  • Choose a size option for CPU, memory, and disk allocation.
  • Disk allocation also determines future transfer limits: stored imports scale to twice disk within 1–20 GiB, and expanded SQL scales to four times disk within 4–64 GiB.
  • Database creation is subject to account database limits even though eligible transfers themselves are available on every active plan.

​
Provisioning lifecycle

Creation is asynchronous. A newly accepted database moves through provisioning before it reaches running. Wait for running and healthy state before wiring an application or starting Import / Export. If creation fails, preserve the database ID and safe error instead of creating several duplicate resources while the first operation is unresolved.

​
Choose a connection path

Private access creates no public policy. Direct uses a public listener on the database node. StackShift tunnel gives native database clients an edge hostname and port while the database listener stays private. Hosted and customer-added nodes can use a tunnel when the selected engine and node are qualified. The create form disables tunnel selection if the platform capability is unavailable; after creation, Credentials shows the database-specific eligibility reason. Restricted by IP requires client CIDRs and an expiry. Open to internet requires an explicit exposure acknowledgement and stays active until revoked under managed renewal. Transport and client IP policy are separate choices. API clients that omit transport continue to use direct access.
  • For an external migration client, select StackShift tunnel and allow its source IP under Restricted by IP.
  • A StackShift tunnel needs no public database port on a customer-added node.
  • Public connection details appear only after the policy becomes active.

​
Transfer qualification after creation

PostgreSQL or MySQL becomes transfer-eligible only when the database is running on the qualified hosted V2 containerd runtime with a target node, stable lineage, runtime image digest, and qualification evidence. Redis and connected-node databases remain ineligible even if their normal lifecycle is healthy.

​
After creation

  • Copy the displayed stable hostname, port, database name, username, and TLS information.
  • Keep private access unless a narrow public allowlist or explicit anywhere policy is required.
  • Review metrics, observability, and logs before considering provisioning complete.
  • Configure backup/recovery policy independently from portable Import / Export.

​
Expected result

The database is running, reachable through its stable endpoint, and ready for normal lifecycle or eligible recovery operations.

​
Common failures

  • Trying to connect before the database reaches running.
  • Using a project database through the standalone route family or vice versa.
  • Expecting Redis, a connected-node database, or an unqualified runtime to expose Import / Export.
  • Creating duplicate resources instead of inspecting the first failed provisioning operation.

Database connections and tunneling

Use private, direct public, or StackShift tunnel endpoints with TLS and explicit client IP policy.

Import and export a database

Move complete PostgreSQL or MySQL databases as portable SQL with resumable uploads, private candidates, structural validation, explicit promotion, and 24-hour rollback.

Back up and restore a database

Use durable recovery storage correctly and understand why backups are independent from portable SQL transfers.

Managed database overview

Understand project and standalone databases, stable endpoint identity, supported engines, recovery, and transfer eligibility.