Choose a deployment

Choose a database configuration based on the workload you have measured. Confirm its location, resources, connection methods and recovery options before provisioning. The console preview demonstrates the workflow but does not create infrastructure.

1. 01
   Measure the workloadEstimate stored data, query demand and growth.
2. 02
   Choose resources and regionReview capacity, recovery options and the quote.
3. 03
   Provision the instanceWait for the selected configuration to become ready.
4. 04
   Verify a small workloadTest access, queries and the recovery procedure you require.

Tenant architectureCopy Anchor Link

A tenant is the logical database scope used by the service. A dedicated instance has resources assigned to its deployment. Account and billing settings are managed separately from database operations. Check the actual configuration rather than inferring isolation or availability from a plan name.

Choosing a region + configurationCopy Anchor Link

Review the compute, memory, storage and region offered for your deployment. Confirm any standby, network or recovery requirements in the quote.

Use current pricing for costs. Hourly figures on the website are monthly-price equivalents; they do not change the billing contract. Availability commitments must come from your agreed service terms.

Selecting add-onsCopy Anchor Link

Check the capabilities reported by the deployed instance before depending on SQL, vector, graph, full-text or optional operations. An option in a preview screen is not confirmation that the engine has enabled it.

Confirm the cost and prerequisites of any additional feature in the current quote; this guide does not define a fixed add-on catalog.

ProvisioningCopy Anchor Link

1. Open Instances → New instance and choose an offered configuration.
2. Review the name, region, resources and network settings.
3. Confirm the quote and submit the live provisioning request.
4. Wait for the instance to report ready.
5. Open Connect, copy the supplied values and run a small read.

Provisioning time depends on the deployment. A preview entry or submitted request is not proof that the database is ready.

DNS & TLSCopy Anchor Link

Use the complete HTTPS address supplied by Connect. Do not construct a hostname from the instance name. Configure certificate verification as instructed for the endpoint. For PostgreSQL, use its separate host, port and TLS settings.

An endpoint change during recovery may require clients to reconnect; test that behavior in your application.

Bearer rotationCopy Anchor Link

Create a replacement credential, update your application and verify a request before revoking the old one. Revocation in the management service and propagation to engines are separate events. Do not assume an undocumented overlap period. See authentication.

Replication topologyCopy Anchor Link

A primary serves writes; a standby is a second copy prepared for recovery. If replication is asynchronous, the standby can lag behind the primary and may lack recent acknowledged writes after a failure.

Confirm the topology, acknowledgement behavior and promotion procedure for your instance. Synchronous behavior on one endpoint does not establish the same guarantee for every write API. Test recovery with your own workload. See the operations guide and multi-region availability.

Migration from existing dataCopy Anchor Link

Use Migrate for a supported source database, or the write guide for application and batch writes. Verify record counts and representative values before switching your application. Keep the source available until the destination checks pass.