How managed databases and replicas work

Customer-visible contract

Applications access a database through an environment-scoped binding. BlinkHost resolves that binding for the authenticated project and does not expose platform database credentials to browser code. Database operations remain subject to the project role, runtime policy and plan limits.

Writes, transactions and concurrency

The managed database service remains authoritative for committed state. A transaction groups supported statements so they either commit together or roll back together. Concurrent requests are ordered by the database engine; applications must still use transactions, uniqueness constraints and idempotency keys where two requests may update the same logical record.

An edge replica can accelerate eligible access, but it is not a separate source of truth. Synchronisation is bounded and coordinated per project so ordinary request traffic does not start an unbounded number of sync operations. Applications that require a fresh result immediately after a write should keep that operation within the documented transaction or authoritative request path rather than assuming every geographically distributed read is instantaneous.

Failure and recovery

BlinkHost checks replica health, limits concurrent mounts and synchronisation work, and removes an unhealthy in-memory connection before rebuilding access from authoritative state. A transient replica problem must not be interpreted as a committed-write rollback. The platform exposes bounded errors when freshness or capacity cannot be established safely instead of silently treating uncertain state as current.

Security and privacy boundary

Projects and environments use scoped database capabilities. Data is encrypted in transit and at rest, while service identities and operational access follow least-privilege and audit controls. BlinkHost processes customer database content to provide the service and does not use it for advertising. Do not describe this service as zero knowledge: customers should use application-level encryption with customer-controlled keys for fields that must remain unreadable to any hosting operator.

Customer responsibilities

Use parameterised queries, schema constraints and transactions; do not store plaintext passwords or payment-card secrets; test migrations before production; and select retention and residency options appropriate to the workload. Record the request identifier and UTC time when reporting a database failure, but never include credentials or raw personal data in a support message.