Spanner Database
Does ZopNight manage Spanner Database?
Spanner databases carry no meter of their own. Each one draws on the provisioned processing units and storage of its parent instance, which bills 24x7. ZopNight inventories every database via Cloud Asset Inventory so instance capacity and storage growth can be attributed to the actual workloads consuming them.
Rules that fire on Spanner Database
No active rule family targets Spanner Database today. Rules that used to are retired, and retired rules publish no pages and fire no findings. Scheduling and permissions coverage are unaffected.
A Spanner database lives inside a Spanner instance and consumes its provisioned capacity and storage. Database count and storage growth explain how instance capacity is actually used.
A consumer of capacity, not a line item
Nothing on a GCP invoice names a Spanner database. The parent instance provisions compute and pays for storage; each database inside it draws down that shared pool. That indirection is exactly why the database row matters for cost work. When an instance’s processing units look busy or its storage climbs, the databases are where the explanation lives. Two workloads sharing one instance are invisible to billing but fully visible at the database layer.
Mapping workloads onto the instance they share
ZopDev inventories Spanner databases via Cloud Asset Inventory to attribute instance capacity and storage to the workloads consuming it. The attribution turns a single opaque “Spanner instance” cost into per-workload shares: which schema’s tables hold the bytes, which application’s traffic drives the CPU that justified the current processing-unit count.
Signals a database inventory surfaces
Three findings recur when databases are enumerated rather than assumed. Abandoned databases from finished migrations or deleted services, still holding storage inside a paid instance. Test databases co-tenanted with production on the same instance, entangling their load with production’s capacity sizing. And single-database instances whose storage has been shrinking for months, a hint that the workload is winding down while the provisioned compute stays frozen at its historical size.
Cleanup happens at two different layers
Dropping an unused database frees the storage it held, but compute savings only arrive when the parent instance’s processing units are reduced to match the lighter load; the instance meter does not notice a database’s departure on its own. The pairing is the point: database-level inventory identifies what can go; instance-level rightsizing (tracked on the spanner resource) collects the money.
Listing databases beneath a Spanner instance
Google Cloud console → Spanner → select an instance → Databases shows every database with its size, the fastest way to see which tenants an instance is actually carrying.