Allocate the cost of a shared Cloud SQL database to the teams using it

​

Prerequisites

1. Know what drove the last database cost increase. Use a storage-size metric if storage grew. Use a compute metric if CPU or memory was the constraint.
2. Know where that usage metric lives, for example Datadog or Google Cloud Monitoring.
3. Have a Datadog connection under Integrations. This walkthrough uses the demo connection Docs Datadog. To split on a native GCP series instead, connect GCP Cloud Monitoring and pick a Cloud SQL metric such as cloudsql.googleapis.com/database/postgresql/insights/aggregate/execution_time.

​

What you get

• Each service’s share of the shared Cloud SQL cost.
• Recurring reports so stakeholders see the allocated split.
• Alerts when a service’s share grows unexpectedly.

​

Steps

1

Choose the usage metric

Select the metric that matches your cost driver. The tabs below are example queries for Datadog and Google Cloud SQL.This walkthrough uses a connected Datadog render metric (render.service.cpu.time) as the compute-style driver, grouped by service.name.Storage-size example queries:

• Datadog
• Google Cloud SQL

avg:postgresql.database_size{<yourWhereClause>} by {db}.rollup(avg, daily, 'UTC')

Not available. Use a Datadog-sourced metric instead.

Compute example queries:

• Datadog
• Google Cloud SQL

sum:postgresql.queries.time{<yourWhereClause>} by {user}.rollup(sum, daily, 'UTC')

sum by ("user")(
  rate({
    "__name__"="cloudsql.googleapis.com/database/postgresql/insights/aggregate/execution_time",
    "monitored_resource"="cloudsql_instance_database"
  }[${__interval}])
)

2

Connect the metric as an External metric

Go to Integrations, click + Add integration, then under External metric choose Datadog. Do not use Metrics > Import new metrics datasource.

In this walkthrough Docs Datadog is already connected, so you can skip the connect form and query the metric in the next step. If you still need to connect Datadog, follow Datadog metrics, then click Validate and Save connection.

3

Add Cloud SQL cost and per-service usage

Try the split in Advanced Explorer before you store it as a virtual dimension. Click Explore your data, then switch to Advanced. Classic only accepts cost metrics.

Query Datadog and other external metrics in Advanced Explorer only.

You will build four series. The formula editor does not support SUM(), so the all-services total is its own series. Add cost and per-service usage here. The next step adds the denominator and the formula.

Series	Role	Settings
Cost #1 (a)	Shared Cloud SQL cost	Metric Cost, Aggregate SUM, Group By Service Name, Where Service Name In Cloud SQL
Externalmetric #2 (b)	This service’s usage	Docs Datadog, render.service.cpu.time, Aggregate SUM, Group by service.name
Formula #3 (c)	Allocated cost	a * b / d
Externalmetric #4 (d)	Usage across all services	Same render.service.cpu.time metric, Aggregate SUM, Group by None

a * b / d is shared Cloud SQL cost times this service’s cpu.time, divided by all services’ cpu.time.Configure Cost #1 (a) as in the table. Open Where and set Service Name In Cloud SQL.

Click + Add Metric, open integrations, and choose Docs Datadog. Search render, then pick render.service.cpu.time. Set Aggregate to SUM and Group by to service.name.

Use SUM when you later aggregate this metric at weekly or monthly levels. A maximum aggregation can over-allocate cost to the service that spiked on a single day.

4

Add the usage total and the allocation formula

Click + Add Metric again. Pick the same Docs Datadog metric render.service.cpu.time, Aggregate SUM, Group by None. That series is Externalmetric #4 (d), the denominator.Set Formula #3 (c) to a * b / d. Toggle the checkboxes on each series so you can inspect the allocated series on its own.

5

Create a virtual dimension scoped to Cloud SQL

Store the split so you can reuse it in group-bys, reports, and alerts.Go to Dimensions, click + Add new dimension, then Virtual dimension.

Name it cloud sql reallocated. The modal accepts lowercase letters, numbers, and underscores.

On Rule 1, set the condition Where Service Name In Cloud SQL. That scopes the shared cost this rule reallocates.Open Allocate costs by: and select Dynamic based on usage metric. That is Dynamic Allocation: Costory splits the scoped cost in proportion to the usage series.

Set Integration to Docs Datadog, Metric to render.service.cpu.time, and Split by to service.name. Aggregate stays SUM.

6

Map metric values and save a draft

Map Datadog service.name values to dimension values. You can use identity pass-through, a regex, or a manual map.

Mapping	How you set it	When to use
Identity (pass-through)	Click Switch to identity, or check Set with Regex and keep [\s\S]*	service.name values are the dimension values you want
Regex	Check Set with Regex and edit the pattern	You need to extract a team or service token from the metric value
Manual	Pick Select a value for each metric label	Labels have no relation to the dimension values

This walkthrough uses identity pass-through: check Set with Regex and keep [\s\S]*. The helper text reads Identity pass-through: metric values are used as dimension values (regex [\s\S]*).

If you choose manual mapping and a new service appears later, edit the virtual dimension to map that service.

Click Save draft. A draft does not appear in Explorer group-by until you Publish. This walkthrough stops at the draft.

The Costory MCP can build this from chat: “draft a virtual dimension that allocates my shared Cloud SQL cost using render.service.cpu.time grouped by service.name, preview it, then save a draft.”

7

Publish and create a report

After you Publish, go to Explorer and create a new report grouped by cloud sql reallocated. You can also schedule the report to Slack on a weekly or monthly basis. See Cost Reports.

​

Troubleshooting

​

Related

• To allocate a shared API instead of a database, see Split Shared API Costs Across Teams. That guide uses an external usage metric such as API call counts.
• Connect Datadog or another usage source from usage metrics.
• See Shared Cost Allocation for mapping types and other shared infrastructure patterns.
• Virtual dimension rules live in Dimensions.