The issue is mainly because of the Snowflake network policy restricting access based on IP.
A local development machine usually does not have a guaranteed static public IP unless it is provided through your network setup. Even if your device shows a fixed IP internally, the public IP seen by Snowflake can still change because of ISP/NAT behavior.
Instead of removing the Snowflake network policy, I would suggest a few options:
1.Use a corporate VPN / fixed egress IP
This is the common approach. Configure the VPN gateway/firewall with a static public IP and whitelist that IP in Snowflake. Then all developers connect through VPN while testing locally.
2.Use a development Snowflake policy
Keep the acceptance/prod policy strict, but have a separate development rule/environment where approved developer IP ranges are allowed.
3.Use a proper development environment
If the application must always run from a fixed IP, use a development VM/server with a static outbound IP instead of a personal machine.
I would avoid changing the acceptance database security just for local testing because it reduces the purpose of the network policy.
Also, before using a VM, check the VM network configuration. The performance issue may be due to resource allocation rather than the approach itself.
Kindly mark this as the accepted answer if it helps.