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 PostgreSQL, MySQL, or Redis and an available size/storage option.
3
Wait for provisioning to reach running before retrieving final connection information or starting a transfer.
4
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 the engine: PostgreSQL, MySQL, or Redis.
  • 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.

​
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.

Credentials, pooling, and usage expectations

Use stable connection details, TLS, public-access policy, and pooler endpoints without relying on physical runtime addresses.

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.