Design, migrate, and run scalable, highly available databases on Google Cloud across relational and NoSQL services, and track your readiness for the Professional Cloud Database Engineer exam.
Prepare and test your skills
Prepare and test your skills
Billing structures and commitment strategies control how database costs are calculated and how much an organization saves by committing to predictable use. On-demand pricing bills for actual consumption with no commitment, committed use discounts (CUDs) lower the rate for a one-year or three-year commitment, and serverless consumption scales cost with traffic. The best choice depends on workload predictability, performance needs, and total cost of ownership (TCO) (opens in a new tab).
On-demand pricing is a pay-as-you-go model with no upfront commitment where charges are based on resources consumed. Oracle Database@Google Cloud under the public offer bills consumption such as OCPUs per hour and storage per GB at public list price, with charges shown as line items in the monthly Google Cloud invoice. BigQuery also offers on-demand pricing where analysis is billed per use, which fits testing, short-term work, and fluctuating demand. Choose on-demand when usage is unpredictable, spiky, or too new to forecast for a one-year or three-year commitment.
Commitment-based discounts reduce the billing rate when an organization agrees to a minimum spend or usage level for one year or three years. The central FinOps team typically manages these commitments because it can see needs across the organization and aggregate them for maximum savings, while product and engineering teams manage resource sizing. Committed use discounts (CUDs) can be stacked on top of enterprise discounts for significant additional savings, and commitments can be set to auto-renew so coverage does not lapse. Compute Engine (opens in a new tab) resource commitments can be shared across projects, which lets one purchase cover matching use elsewhere.
| Discount type | What is committed | Scope where discount applies |
|---|---|---|
| Enterprise discounts | Minimum total Google Cloud spend at a negotiated reduced rate | Organization commitment applied to overall spend |
| Resource-based CUDs | Minimum quantity of Compute Engine resources for one year or three years | Specific region, with sharing across all projects in most Cloud Billing accounts |
| Spend-based CUDs | Minimum spend on a particular product for one year or three years | Billing account level, applied regionally or globally depending on the product |
Resource-based sharing means a commitment bought in one project can cover matching regional usage in other projects under the same billing account. For databases with significant or long-term needs, a private offer extends this idea by negotiating custom pricing through Google Cloud Marketplace. A private offer can reflect contract length, CUDs, or the number of Exadata deployments while keeping consolidated billing through Google Cloud.
Exam tip: Resource-based CUDs commit to a quantity in a specific region, while spend-based CUDs commit to a spend amount at the billing account level.
Serverless consumption bills for capacity actually used and automatically scales instances with demand instead of charging for provisioned servers. Cloud Run provides built-in autoscaling where the number of instances increases when incoming traffic rises and decreases when traffic falls to reduce cost. For more predictable traffic, always-allocated CPUs cost a fraction of the default method where CPUs are allocated only during request processing, and BigQuery edition-based pricing with slot commitments lowers the cost per slot for high-volume analytics compared with on-demand. Choose serverless and autoscaling when traffic varies, because the service adds resources only when needed and avoids over-provisioning.
Flexible capacity options further lower rates for workloads that do not need a full commitment:
Total Cost of Ownership compares the full cost of running a database in Google Cloud with self-hosting, not just hardware and software prices. Self-hosted costs include dedicated engineering for patching, scaling, security hardening, and disaster recovery, plus power, cooling, maintenance, support services, and cloud network charges for data transfer. Managed services offset infrastructure charges with built-in reliability, compliance capabilities, and lower operational overhead, and elastic scalability makes it easier to reduce cost than in a rigid on-premises data center.
Region selection and billing operations also affect TCO. Different regions have different prices, so teams balance cost objectives against latency, compliance, and sustainability needs, often using the Google Cloud Region Picker to compare trade-offs. For Oracle Database@Google Cloud, Cloud Billing (opens in a new tab) consolidates charges through an ordered flow:
A prepaid private offer changes this flow by processing a one-time upfront charge upon acceptance for a fixed term or entitlement. Later related line items then typically appear as $0.00 because the upfront payment already covers them, and only usage beyond the prepaid capacity, limits, or duration creates new overage line items.
Storage, networking, and data lifecycle costs together determine the total cost of ownership of a database solution on Google Cloud. Storage location and tier set the base price for data at rest, network egress adds a usage-based charge for moving data between regions, and lifecycle management controls how fast retained data grows over time.
Storage location choice determines both the unit price for data and whether replication charges apply. Cloud Storage (opens in a new tab) bills dual- and multi-region buckets at different prices than single-region buckets and separately charges for inter-region replication. Compute Engine instance prices also differ from region to region, so the same database infrastructure can cost more or less depending on where it is provisioned. A regional deployment keeps data in one region, while a dual- or multi-region deployment automatically replicates data across regions for higher reliability at higher product cost.
| Deployment option | Price characteristics | Choose when |
|---|---|---|
| Single-region storage and compute | Lower storage unit price with no inter-region replication charge; region-specific compute price applies | Data and workloads tolerate zonal redundancy and do not need protection from a regional outage |
| Dual- or multi-region storage | Higher storage unit price plus inter-region replication charge; Cloud Storage handles replication across regions | Reliability requirements demand survival of a regional outage for critical data and workloads |
Provision multi-region replication and distribution only when reliability requirements justify the extra cost. For example, data that does not need protection from a regional outage can stay in a single-region bucket, and a non-critical workload can run in a single region or single zone. Before chasing a cheaper region, confirm that the workload tolerates the added latency to resources in other regions, meets regulatory requirements for locality, and does not create inter-region traffic that cancels the savings.
Networking costs in Google Cloud are usage-based charges that behave differently from on-premises networks. In a data center, routers, switches, and cabling are one-time purchases that allow use of the full network capacity, while in Google Cloud many flows are billed for network utilization. Google Cloud charges for network traffic between regions as egress traffic, so data-intensive workloads that exchange large volumes across regions can dominate TCO. To lower cost, concentrate closely related resources that exchange data in the same region, such as provisioning a Compute Engine instance in a region where the Cloud Storage bucket it reads from replicates data.
Assessing a future migration across regions requires estimating four related costs: the price of resources in the target region, the cost of multi-region resources, the egress traffic for the move, and the collateral work to complete it. The target-region price is estimated with the Google Cloud Pricing Calculator for new compute, storage, and data transfer. Dual- or multi-region buckets may already replicate data into the target region and avoid a separate migration, while the move itself incurs egress charges from the source region plus time, training, and planning costs.
Exam tip: Avoid inter-region egress by co-locating compute with the data it uses, and choose a multi-region bucket only when automatic replication across regions is required for reliability.
Data lifecycle management is the practice of automatically controlling how long database data, backups, and objects are kept and where they are stored. Stored data can grow to significant amounts in a short time, so retaining every detail forever steadily increases the storage bill. An effective lifecycle moves data through stages: first delete data that is no longer needed, then generate smaller aggregate data from detailed data and keep only the aggregate long term, then move infrequently accessed data to less expensive systems designed for infrequent access.
Cloud Storage provides two automated controls for this lifecycle. Object Lifecycle Management automates typical lifecycle actions on objects, such as deletion or class changes, while Autoclass automatically transitions each object to the appropriate storage class based on its access pattern. Applied to database exports, backups, and archival copies, these controls enforce retention policy without manual cleanup and keep infrequently read retention from accumulating at high-performance storage prices.
Managed versus self-managed is a choice about who carries database operations work and how that work shows up in total cost. A fully managed service like Cloud SQL (opens in a new tab) runs the database on Google-managed infrastructure and handles administration, while a self-managed instance like SQL Server on Compute Engine gives full control of the virtual machine (VM) but leaves patching, scaling, hardening, and recovery to your team. For financial-services and other critical workloads, managed services often deliver higher long-term value because built-in reliability, compliance capabilities, and lower operational overhead offset higher infrastructure charges.
Cloud SQL is a fully managed relational database service for MySQL, PostgreSQL, and SQL Server that frees you from routine database administration. You focus on data and schema changes while Cloud SQL handles the surrounding platform operations.
Cloud SQL handles operations that you would otherwise build yourself:
Each Cloud SQL instance is powered by a VM running the database program plus service agents for logging and monitoring. The database files live on a scalable persistent disk attached to the VM, and a static IP address sits in front of the VM so applications keep the same connection address. When you enable high availability, Cloud SQL adds a standby VM in another zone with a configuration identical to the primary VM.
Total cost of ownership (TCO) for databases includes far more than VM size and storage. A complete TCO model adds hardware and software, power, cooling, maintenance, support services, cloud network utilization, and dedicated engineering labor for operations. Cloud networking is commonly overlooked because on-premises network cabling is a one-time cost, while in Google Cloud you can be billed for network utilization, which matters for data-intensive workloads.
Licensing is a major cost boundary between the two models. When you run a database like Microsoft SQL Server on Compute Engine VMs, you must separately account for third-party software license costs. When you use a managed service like Cloud SQL, database license costs are included in the service charges. Managed pricing then varies with provisioned storage in GiB per month, selected CPUs and memory, hosting region, network traffic leaving the instance, and assigned IP addresses.
Maintenance labor is where managed and self-managed diverge most clearly. Cloud SQL divides updates into user-driven configuration updates and Google-driven system updates. Configuration updates include increasing compute resources, modifying a database flag, and enabling high availability, and some of these updates can require downtime.
Cloud SQL performs system updates for you in three categories:
A self-managed database on Compute Engine depends on your team for the same outcomes. You must track CPU utilization, memory load, disk-space utilization, service status, unplanned failovers, replication lag, transaction rates, and active connections, plus create log-based alerts for deadlocks, corruption, and agent job failures. You must also isolate the instances with private IP addresses in a Virtual Private Cloud (VPC), restrict traffic with firewall rules, enforce TLS/SSL in transit, manage encryption at rest, and map identities to least-privilege database roles.
Both models benefit from rightsizing and elastic scaling, but the controls differ. For managed databases, start with minimum required storage with automatic storage increase plus buffer for peaks, remove high availability or disaster recovery where workloads do not require it, delete unneeded tables, and use Active Assist recommendations and Cloud Monitoring dashboards to find overprovisioned instances. For Compute Engine VMs, rightsize machine types after migration, use autoscaling groups where the architecture allows it, keep instance templates deterministic with explicit software versions, and maintain custom OS images with current security patches.
Discounts and storage and licensing choices further change TCO:
Exam tip: Cloud SQL includes the database license in its price, while SQL Server on Compute Engine requires you to account for separate license costs plus the labor to patch, monitor, and secure it.
| Option | What you pay for | Who owns operations |
|---|---|---|
| Cloud SQL | Instance CPUs, memory, provisioned storage, region, egress traffic, and IP use, with license included | Google owns hardware replacement, agent updates, OS and database maintenance, backups, failover, and built-in monitoring |
| Compute Engine self-managed | VM, disks, network use, and separate third-party database licenses, with savings possible from SMT and edition choices | Your team owns OS patching, database upgrades, availability design, backup orchestration, security hardening, and custom monitoring |
Choose a fully managed service like Cloud SQL or Spanner when lower administrative effort, automated maintenance, built-in high availability, and included licensing matter more than low-level control. Choose self-managed instances on Compute Engine when you need custom OS configuration, specific database versions or features, or direct control over failover, storage layout, and performance tuning, and you can staff the ongoing patching, scaling, and recovery work. Validate the tradeoff with a proof of concept that runs the same business logic against candidate databases and compares performance, scalability, consistency, failover, and operating cost before committing the TCO model.
Last updated