Cloud SQL PSC reconciliation is default from 1 August 2026: what quietly breaks
Summary. Google published a Cloud SQL release note on 31 July 2026 and the behaviour took effect the next day. From 1 August 2026, any Cloud SQL instance you create, clone, or enable Private Service Connect on has connection reconciliation switched on by default, and Google's own wording is that it "can't be disabled". Remove a project from that instance's list of allowed projects and every existing Private Service Connect connection from the removed project is closed immediately. Instances created before August 2026 keep the old behaviour, where endpoints in a removed project keep working until someone deletes them by hand. So a single Google Cloud estate now contains two classes of Cloud SQL instance that respond to the same allowlist edit in opposite ways. The --allowed-psc-projects flag exists only on gcloud sql instances create, and Google's configuration guide documents no producer-side command for listing which consumer projects currently hold a live endpoint.
The change, in Google's words
The Cloud SQL for PostgreSQL release notes entry is dated 31 July 2026 and labelled "Change". Its opening line: "Starting on August 1, 2026, when you create or clone a Cloud SQL instance enabled with Private Service Connect, or when you enable Private Service Connect for an existing instance, then connection reconciliation behavior is enabled by default and can't be disabled."
The second paragraph is the operational part. "When you remove a project from the list of allowed projects, all existing Private Service Connect connections from the removed project are immediately closed (reconciled). This means that applications using Private Service Connect endpoints in those removed projects can't continue to connect to the Cloud SQL instance using those endpoints."
Three triggers are named: create, clone, and enabling Private Service Connect on an existing instance. All three are things a platform team does routinely, and the second one deserves a flag on its own. Cloning a production instance to make a staging copy now produces an instance with different revocation semantics from the one it was cloned from.
Two classes of instance in one estate
The Private Service Connect overview page, last updated 22 July 2026, spells out the split that the release note leaves implicit.
For instances created, cloned or PSC-enabled in August 2026 and after, reconciliation is on and cannot be turned off. For instances created before August 2026, the page says that when you remove a project from the allowed list, "applications using Private Service Connect endpoints in those removed projects continue to connect until you manually remove those endpoints."
| Property | Instance created before August 2026 | Instance created, cloned or PSC-enabled from 1 August 2026 |
|---|---|---|
| Reconciliation default | Off | On |
| Can reconciliation be disabled | Not applicable | No |
| Effect of removing a project from the allowlist | New endpoints blocked; existing connections keep working | All existing connections from that project closed immediately |
| How connections actually end | An operator deletes the endpoint | Automatically, on the allowlist edit |
| Blast radius of an allowlist typo | A stale endpoint nobody noticed | Live application traffic to the database |
| What a clone of this instance inherits | The new behaviour, not the old | The new behaviour |
That last row is the trap. Reconciliation is a property of when the instance was created or PSC-enabled, not of the instance it was copied from. A three-year-old production database still behaves the old way. The clone you took of it this morning does not.
There is no field in the API that reports which class an instance falls into. The instance response exposes pscEnabled, allowedConsumerProjects and pscAutoConnections, and none of them says whether reconciliation is active. Creation date is the only signal, so an inventory keyed on creation date is the only inventory that answers the question.
Why the allowlist stopped being a permission and became a switch
Google sold Private Service Connect on exactly this control surface. Shambhu Hegde, Product Manager at Google Cloud, wrote when Private Service Connect became fully integrated with Cloud SQL in April 2024: "When using Private Service Access, you need to allowlist an entire subnet range beforehand when setting egress firewall rules, which can be overly permissive and an operational burden. With Private Service Connect, you can set granular firewall rules, which is better from a security perspective."
Granular is right. What changed on 1 August 2026 is the cost of getting the grain wrong. Until then, allowedConsumerProjects behaved like an admission policy: it decided whether a new endpoint could be created, and Google's configuration guide still describes it that way. A project not on the list can still attempt to create an endpoint, and that endpoint "will stay in a PENDING state until you add that project to the allowlist." Removing a project only closed the door to newcomers.
Now the same field is also a revocation control. That is defensible security design. If a project should no longer reach a database, its live sessions arguably should not survive the decision. The problem is that the field did not move, its name did not change, and nothing in the API tells you which semantics apply to a given instance.
The real risk is not the security model. It is that a list which used to be edited casually is now load-bearing.
The Terraform diff that is now an outage
Google's own Terraform example for a PSC-enabled instance carries the allowlist inline:
resource "google_sql_database_instance" "default" {
name = "postgres-instance"
region = "us-central1"
database_version = "POSTGRES_14"
settings {
tier = "db-custom-2-7680"
availability_type = "REGIONAL"
backup_configuration {
enabled = true
}
ip_configuration {
psc_config {
psc_enabled = true
allowed_consumer_projects = []
}
ipv4_enabled = false
}
}
}
Note that allowed_consumer_projects is an empty list in the sample. In a real repository it holds project IDs, often assembled from a variable, a for_each, or a module output. Three ordinary changes now carry production consequences:
A project ID dropped from a locals block or a tfvars file, because a team was decommissioned or a module was refactored. The plan shows a change to a list attribute. The apply closes every session from that project.
A module upgrade that changes how the list is computed. If the new version emits project numbers where the old one emitted project IDs, the strings differ even though the intent has not, and the old entries are removed.
A drift correction. Someone added a project through the console during an incident, the list in code never caught up, and the next terraform apply removes it.
Before 1 August 2026 all three produced a harmless diff. From 1 August 2026 they produce a connection reset, on instances created or cloned after that date, with no confirmation step and no way to opt out.
Treat allowed_consumer_projects the way you treat a deletion protection flag or a database name: put it behind a required review, and never let a plan that touches it merge without someone naming which consumer projects are about to lose access.
You cannot see your blast radius from the producer side
This is the finding that should shape your runbook. Google's configuration guide documents no command that lists which consumer projects currently hold a live endpoint against an instance. The nearest surfaces all fall short in a specific way.
The instance description shows auto-created connections only:
gcloud sql instances describe INSTANCE_NAME \
--project=PROJECT_ID \
--format='json(settings.ipConfiguration.pscConfig.pscAutoConnections)'
That returns consumerNetwork, consumerNetworkStatus, consumerProject, ipAddress and status for endpoints that Cloud SQL provisioned itself through a service connection policy. Endpoints created manually, which is the documented path whenever you reserve your own internal IP, do not appear.
The full instance response exposes the permitted list, not the connected one:
gcloud sql instances describe INSTANCE_NAME --project=PROJECT_ID
Inside settings.ipConfiguration.pscConfig you get allowedConsumerProjects, pscAutoConnections, pscEnabled and, alongside them, pscServiceAttachmentLink. Google's glossary describes allowedConsumerProjects as "a list of the allowed projects for the instance", which is precisely the point: it tells you who may connect, not who is connected.
The only per-connection view lives on the consumer side, and you need the endpoint name and access to that project first:
gcloud compute forwarding-rules describe ENDPOINT_NAME \
--project=PROJECT_ID \
--region=REGION_NAME
That returns pscConnectionId, pscConnectionStatus (ACCEPTED when the link is live), allowPscGlobalAccess and a target pointing at the service attachment.
So the audit has to run the wrong way round. Start from the allowlist on each instance, then go into each of those projects and enumerate forwarding rules whose target is that instance's pscServiceAttachmentLink. In a shared-VPC organisation with dozens of consumer projects, that is an inventory job, not a command. Build it once, schedule it, and store the output next to the instance inventory.
A safe change procedure
Removing a project from an allowlist is now a change with a customer-visible failure mode. Give it the same treatment as a schema migration.
Establish which class the instance belongs to. Check its creation date against 1 August 2026. If it was created, cloned or PSC-enabled on or after that date, reconciliation is live.
Enumerate the endpoints in the project you are about to remove. Use the consumer-side forwarding-rules describe against each candidate endpoint name and confirm which ones show pscConnectionStatus: ACCEPTED for the target instance.
Drain before you revoke. Move the workload's connections onto an endpoint in a project that is staying on the list, or stop the workload, and confirm the sessions are gone from the database before touching the allowlist. Do not rely on the client reconnecting; the endpoint in the removed project no longer resolves to a permitted path.
Delete the endpoint, then remove the project. On a pre-August instance this order is required anyway, because the connection survives the allowlist edit. On a post-August instance it makes the change a no-op instead of a cutover.
Make the change in one place. --allowed-psc-projects appears on gcloud sql instances create and, in Google's documentation, on no patch command at all. Teams that change the list through the console or the API while Terraform owns allowed_consumer_projects are building a drift correction that will one day sever a live connection.
Record what you did. There is no producer-side connection log to reconstruct from afterwards.
Where this sits against the rest of your networking
Private Service Connect is still the right default for Cloud SQL at scale, and the reasons have not changed. Google's own comparison against private services access is that peering-based connectivity is cumbersome when several VPC networks need one instance, reserves an entire subnet range per region, forces overly permissive egress rules, and runs into VPC peering quotas. Private Service Connect needs one IP address per endpoint, and each network gets its own.
Two properties are worth restating because they interact with the reconciliation change.
Private Service Connect connections are not transitive from peered VPC networks. You need an endpoint in every network that must reach the instance, so three networks means three endpoints and three consumer projects on your allowlist. More entries means more chances for one of them to be edited by accident. Network Connectivity Center hub propagation can collapse this by making endpoints in a common services VPC reachable from other spokes, which shrinks the allowlist to one project and makes the change surface smaller.
Each instance has exactly one service attachment, and every replica is a separate instance with a separate attachment and endpoint. A cross-region read replica used for disaster recovery therefore has its own allowlist. Teams practising failover should confirm both the primary and the replica allowlists before a drill, not just the primary. The same discipline applies as in a cross-region failover setup: the thing that fails during a drill is usually the one control nobody re-checked.
India-specific considerations
Cloud SQL region choice already carries a cost difference for Indian teams. On Google's published Cloud Run rate card, Mumbai (asia-south1) sits in Tier 1 pricing while Delhi (asia-south2) sits in Tier 2, and the same tiering logic runs across Google Cloud regions. Teams splitting a primary and a disaster recovery replica across those two regions are paying two different rates for the two halves of the same estate.
The reconciliation change lands harder in the deployment pattern most common among Indian services businesses and product teams serving multiple clients: one shared services VPC, many consumer projects, one database per tenant. That is precisely the multi-tenant SaaS shape Google cites as a reason to use Private Service Connect, and it is the shape with the longest allowlists. A list with fifteen project IDs and a monthly onboarding cadence is a list that will be edited, and every edit after 1 August 2026 is now a potential production incident on instances created since.
For teams operating under India's Digital Personal Data Protection Act 2023, the change is also a small improvement worth writing down. Revoking a project's access now genuinely ends its sessions rather than leaving them running until someone tidies up, which is a cleaner story for an access-review control. Document it in the same place you document data residency and cloud architecture decisions, and pair it with the multi-region resilience work that owns the replica allowlists. The wider cost and control picture is covered in the cloud FinOps guide for Indian teams.
What to check this week
| Check | Where | Why it matters now |
|---|---|---|
| Creation date of every PSC-enabled Cloud SQL instance | Instance inventory | Only date tells you which reconciliation class applies |
| Instances cloned since 1 August 2026 | Clone and restore records | A clone gets the new behaviour regardless of its parent |
Every allowed_consumer_projects in Terraform |
Infrastructure repository | A list edit is now a connection reset |
| Who can approve a change to that attribute | Repository review rules | The control needs a named owner |
| Endpoints in each allowlisted project | Consumer-side forwarding rules | There is no producer-side inventory |
| Replica allowlists, not just primaries | Each replica instance | Every replica has its own service attachment |
| gcloud version in your build images | CI configuration | Private Service Connect support requires gcloud 416.0.0 or later |
The last row is a small thing that bites at the wrong moment. Google states Private Service Connect support from gcloud CLI 416.0.0 and later, and a pinned older image in a pipeline will fail in a way that looks like a permissions problem rather than a version problem.
One more caution on tooling. Cloud SQL's DNS automation feature, which provisions per-instance and write-endpoint DNS records for you, is still labelled Preview under Google's Pre-GA Offerings Terms, its commands run under gcloud beta sql instances, and Google states that configuring it through the console or with Terraform is not supported. If your endpoint names are managed by that feature, your audit script cannot assume Terraform is the source of truth for DNS.
FAQ
What exactly changed for Cloud SQL on 1 August 2026?
Google's Cloud SQL release note of 31 July 2026 states that from 1 August 2026, creating or cloning a Private Service Connect enabled instance, or enabling Private Service Connect on an existing one, turns on connection reconciliation by default, and that the behaviour cannot be disabled. Removing an allowed project then closes its connections immediately.
Does this affect Cloud SQL instances I created last year?
No. Google's Private Service Connect overview states that for instances created before August 2026, applications using endpoints in a removed project continue to connect until you manually remove those endpoints. Those instances keep the old behaviour, which means one estate can hold two classes of instance responding differently to the same allowlist edit.
Can I turn connection reconciliation off?
No. The release note wording is that the behaviour "is enabled by default and can't be disabled" for instances created, cloned or Private Service Connect enabled from 1 August 2026 onwards. There is no documented flag, API field or console setting to opt out, and no field in the instance response that reports whether it is active.
How do I see which projects currently have a live endpoint?
Google's configuration guide documents no producer-side command for this. The instance description shows only auto-created connections under pscAutoConnections, and allowedConsumerProjects lists who may connect rather than who is connected. Enumerating forwarding rules in each allowlisted project and matching them to the instance's pscServiceAttachmentLink is the workaround.
Does a clone of an old instance inherit the old behaviour?
No. The release note names clones explicitly alongside creations and Private Service Connect enablements. A clone taken on or after 1 August 2026 gets reconciliation enabled by default even when the source instance predates the change, so staging copies of long-lived production databases behave differently from their parents.
How do I change the allowed projects list safely?
Confirm the instance's creation date, enumerate endpoints in the project you plan to remove using gcloud compute forwarding-rules describe, drain or stop the workload, delete the endpoint, and only then remove the project from the list. Keep the list in one place, because console edits alongside Terraform ownership create drift that later severs connections.
Do read replicas need separate attention?
Yes. Google states that each Cloud SQL instance has one service attachment, and each read replica is a separate instance with its own endpoint. A cross-region replica used for disaster recovery therefore carries its own allowed-projects list, so a failover drill should verify the replica's allowlist as well as the primary's.
Is Private Service Connect still preferable to private services access?
For most estates, yes. Google's comparison notes that private services access makes simultaneous access from several VPC networks cumbersome, requires reserving a whole subnet range per region, forces broad egress rules, and runs into VPC peering quotas. Private Service Connect needs one IP address per endpoint and supports granular firewall rules.
How eCorpIT can help
eCorpIT builds and audits the network and database layer that this change touches: shared-VPC estates, Private Service Connect endpoints across consumer projects, Terraform ownership of the allowlists, and the failover drills that prove a replica actually works. Our senior engineering teams build the endpoint inventory Google does not ship, put the allowlist behind a review gate, and separate pre-August instances from post-August ones before somebody discovers the difference during an incident. We are CMMI Level 5 assessed and ISO 27001:2022 certified, and we design cloud architectures aligned with DPDP requirements. If you are running cloud migration and modernisation work or tightening multicloud security posture, talk to us about auditing the Private Service Connect estate first.
References
- Cloud SQL for PostgreSQL release notes, entry dated 31 July 2026 — Google Cloud
- Private Service Connect overview, Cloud SQL for PostgreSQL, last updated 22 July 2026 — Google Cloud
- Connect to an instance using Private Service Connect — Cloud SQL for PostgreSQL
- Private, secure, and smooth connectivity to Cloud SQL using Private Service Connect — Shambhu Hegde, Product Manager, Google Cloud, 11 April 2024
- Private Service Connect overview, Cloud SQL for MySQL — Google Cloud
- Private Service Connect overview, Cloud SQL for SQL Server — Google Cloud
- Configure both private services access and Private Service Connect — Cloud SQL for PostgreSQL
- Private Service Connect propagated connections overview — Network Connectivity Center
- Private Service Connect — Virtual Private Cloud documentation
- About service connection policies — Virtual Private Cloud
- Cloud Run pricing, regional price tiers — Google Cloud
- Google Cloud release notes
Last updated: 3 August 2026.
Top comments (0)