fix(rdb): vpc routing (#5073)

* fix(rdb): vpc routing

* fix(rdb): remove mentions of db in vpc

* fix(rdb): routing

Co-authored-by: Jessica <[email protected]>

* Update connect-database-private-network.mdx

update frontmatter

* Update understanding-nacls.mdx

update frontmatter

* Update understanding-routing.mdx

update frontmatter

* fix(vpcrdb): correct routing info

---------

Co-authored-by: Jessica <[email protected]>
Co-authored-by: numa <[email protected]>
Co-authored-by: Rowena <[email protected]>

Author: 4 people

pages/managed-databases-for-postgresql-and-mysql/how-to/connect-database-private-network.mdx

@@ -18,18 +18,21 @@ This improves performance by reducing the latency between your application and y
 
 You can create new Database Instances to attach to your Private Network, or attach existing ones.
 
-<Requirements />
+<Message type="note">
+  Managed PostgreSQL and MySQL Database Instances created after July 28th 2025 are compatible with the [VPC routing](/vpc/concepts/#routing) feature, which allows you to connect one or more Database Instances in a Private Network to resources in other Private Networks of the same VPC. Maintenance scheduled for later in August 2025 will make all pre-existing Managed PostgreSQL and MySQL Database Instances compatible as well. Refer to the [How to manage routing](/vpc/how-to/manage-routing/) documentation page for more information about VPC routing.
+</Message>
 
+<Requirements />
 - A Scaleway account logged into the [console](https://console.scaleway.com)
 - [Owner](/iam/concepts/#owner) status or [IAM permissions](/iam/concepts/#permission) allowing you to perform actions in the intended Organization
 - A valid [API key](/iam/how-to/create-api-keys/)
 - A [PostgreSQL or MySQL Database Instance](/managed-databases-for-postgresql-and-mysql/quickstart/)
 
 ## How to attach a Database Instance to a Private Network
 
-  <Message type="note">
-      You can only attach your Database Instance to one Private Network at a time.
-  </Message>
+<Message type="note">
+  You can only attach your Database Instance to one Private Network at a time.
+</Message>
 
 1. Click **PostgreSQL and MySQL** under **Databases** on the side menu. A list of your Database Instances displays.
 2. Select the geographical region of the Instance you want to manage from the drop-down.
@@ -72,4 +75,4 @@ This action takes a few moments to complete. During this time, your Database Ins
   - remains available,
   - goes into **Configuring** mode, and
   - network configuration actions become unavailable
-</Message>
+</Message>

pages/vpc/faq.mdx

@@ -34,10 +34,6 @@ Yes, [VPC routing](/vpc/concepts#routing) allows you to automize the routing of
 
 This is not currently possible. You may consider using a VPN tunnel to achieve this, for example [IPsec](https://en.wikipedia.org/wiki/IPsec) or [WireGuard](https://en.wikipedia.org/wiki/WireGuard). Scaleway also offers an [OpenVPN InstantApp](/tutorials/openvpn-instant-app/), making it easy to install a VPN directly on an Instance.
 
-### Why can I not route traffic to my Managed Database on another Private Network?
-
-Managed Databases do not currently support VPC routing - see our [dedicated documentation](/vpc/reference-content/understanding-routing/#limitations)
-
 ### Can I control traffic flow between my VPC's Private Networks?
 
 Yes, use the [Network ACL feature](/vpc/reference-content/understanding-nacls/) to filter packets flowing between the different Private Networks of your VPC. By default, all traffic is allowed to pass, until you start to add rules to the VPC's NACL.
@@ -46,6 +42,10 @@ Yes, use the [Network ACL feature](/vpc/reference-content/understanding-nacls/)
 NACLs are currently in Public Beta, and configurable only via the [VPC API](https://www.scaleway.com/en/developers/api/vpc/) and developer tools. This feature will be coming soon to the Scaleway console.
 </Message>
 
+### Why can I not route traffic to my Managed Database on another Private Network?
+
+Only Managed PostgreSQL and MySQL Database Instances created after July 28th 2025 are compatible with [VPC routing](/vpc/concepts/#routing). Maintenance scheduled for later in August 2025 will make all pre-existing Managed PostgreSQL and MySQL Database Instances compatible as well. 
+
 ### How are NACLs different from security groups?
 
 [Security groups](/instances/how-to/use-security-groups/) filter **public** traffic on your Instances, whereas NACLs filter traffic to/from Private Networks only.

pages/vpc/how-to/manage-routing.mdx

@@ -18,7 +18,7 @@ Routing is used to manage and control the flow of traffic within a VPC. It tells
 Read more about the VPC routing feature, including detailed explanations, usage considerations, limitations and best practices in our [dedicated reference content](/vpc/reference-content/understanding-routing/).
 
 <Requirements />
- 
+
   - A Scaleway account logged into the [console](https://console.scaleway.com)
 
 ## How to activate routing
@@ -44,7 +44,7 @@ To activate routing on a pre-existing VPC, follow these steps:
 If you created your VPC before July 1st 2025, you must manually update its routing behavior in order to get the following capabilities:
 
 - Advertisement of custom routes across the entire VPC as standard.
-- Option to enable each Private Network in the VPC to receive default route advertisements not only from their locally attached Public Gateways, but from other Public Gateways (or default custom routes) attached to different Private Networks throughout the whole VPC. 
+- Option to enable each Private Network in the VPC to receive default route advertisements not only from their locally attached Public Gateways, but from other Public Gateways (or default custom routes) attached to different Private Networks throughout the whole VPC.
 
 For more information on these new routing behaviors, see our [detailed documentation](/vpc/reference-content/understanding-routing/#updating-routing-behavior).
 
@@ -78,10 +78,10 @@ Your VPC's **route table** can be found in its **Routing** tab. The route table
 
     Routes are automatically generated and added to the route table when you:
 
-    - Create a Private Network in the VPC (this generates a **local subnet route**, which allows the VPC to automatically route traffic between Private Networks), or 
+    - Create a Private Network in the VPC (this generates a **local subnet route**, which allows the VPC to automatically route traffic between Private Networks), or
     - Attach a Public Gateway to a Private Network and set it to advertise a default route. This generates a **default route to the internet**.
     - Create a custom route
-    
+
     When your route table starts to populate, it will look something like this:
 
     <Lightbox image={image} alt="" />
@@ -93,12 +93,12 @@ Your VPC's **route table** can be found in its **Routing** tab. The route table
 Two types of auto-generated routes exist for VPCs:
 
 - **Local subnet route**: Generated when you create a Private Network in a VPC. Allows traffic to be routed between different Private Networks in the VPC.
-- **Default route to internet**: Generated when you attach a Public Gateway to a Private Network in the VPC, and set it to advertise a [default route](/public-gateways/concepts/#default-route). Allows traffic to be routed to addresses outside the VPC (i.e. the public internet) via the gateway. 
+- **Default route to internet**: Generated when you attach a Public Gateway to a Private Network in the VPC, and set it to advertise a [default route](/public-gateways/concepts/#default-route). Allows traffic to be routed to addresses outside the VPC (i.e. the public internet) via the gateway.
 
 <Message type="note">
-By default, Public Gateways remain scoped to the Private Network(s) to which they are attached. They do not, as standard, advertise the default route on other Private Networks in the VPC. 
+By default, Public Gateways remain scoped to the Private Network(s) to which they are attached. They do not, as standard, advertise the default route on other Private Networks in the VPC.
 
-However, each Private Network can opt in to receive default route advertisements from across the entire VPC, rather than only from locally attached gateways. This allows them to find a route to the internet even if there is no Public Gateway or default custom route on their own Private Network. See our [dedicated documentation](/vpc/reference-content/understanding-routing/#default-routes) for full details. 
+However, each Private Network can opt in to receive default route advertisements from across the entire VPC, rather than only from locally attached gateways. This allows them to find a route to the internet even if there is no Public Gateway or default custom route on their own Private Network. See our [dedicated documentation](/vpc/reference-content/understanding-routing/#default-routes) for full details.
 </Message>
 
 You cannot delete managed routes, as their lifecycle is fully managed by Scaleway. The route will be automatically deleted for you when you delete the Private Network or Public Gateway that it concerns.
@@ -136,10 +136,10 @@ Each Private Network must individually opt in to receive all these default route
 
             3. Click the **Manage default routes** button.
 
-                A screen displays, showing a list of all the Private Networks in your VPC. 
-                
+                A screen displays, showing a list of all the Private Networks in your VPC.
+
                 The **Local default route** column shows whether or not a default route is already advertised locally in the Private Network via an attached Public Gateway or custom route.
-            
+
             4. Click the checkbox next to each Private Network that you want to receive all default routes from throughout the VPC.
 
             5. Click **Apply scope** when finished.
@@ -149,7 +149,7 @@ Each Private Network must individually opt in to receive all these default route
         </TabsTab>
     </Tabs>
 
-### How to view VPC routes in IPv6 
+### How to view VPC routes in IPv6
 
 Scaleway VPC routing supports both IPv4 and IPv6 protocols. Managed routes to Private Networks are simultaneously generated for both IPV4 and IPV6, and both are added to the route table. Use the toggle above the route table to switch from the default view of **IPV4** routes to a view of **IPV6** routes.
 
@@ -193,7 +193,7 @@ Follow the steps below to define a custom route:
 
 8. Enter a **next hop** for the route. The VPC will route traffic for the destination IP to the resource designated as next hop.
     - Select the Private Network which the next hop resource is attached to.
-    - Select a resource type: **Instance**, **Public Gateway** or **Elastic Metal**. Routing is not yet compatible with Managed Databases, nor with other types of Scaleway resources which are not integrated with VPC. 
+    - Select a resource type, e.g. **Instance**, **Public Gateway** or **Elastic Metal**.
     - Select the **name** of the specific resource you want to route traffic to. The resource must be attached to a Private Network in this VPC.
 
     <Message type="note">
@@ -206,15 +206,15 @@ Follow the steps below to define a custom route:
 
 ### How to fix a broken custom route
 
-If you delete a resource used as a next hop in a custom route, or detach it from the Private Network, the custom route will cease to function. A **Not found!** warning will display in the **Next hop** column for this route in the route table. 
+If you delete a resource used as a next hop in a custom route, or detach it from the Private Network, the custom route will cease to function. A **Not found!** warning will display in the **Next hop** column for this route in the route table.
 
     <Lightbox image={image3} alt="A VPC route table displays in the Scaleway console, with a red 'Not found!' text in the next hop column of a custom route" />
 
 To resolve this, you must either:
 
 - [Reattach the next hop resource to the Private Network](/vpc/how-to/attach-resources-to-pn/#how-to-attach-a-resource-to-a-private-network) **and** then [edit the route](#how-to-edit-a-custom-route) to reselect the next hop resource, or
 - [Edit the route](#how-to-edit-a-custom-route) to select a new next hop, or
-- [Delete the route](#how-to-delete-a-custom-route) 
+- [Delete the route](#how-to-delete-a-custom-route)
 
 ## How to edit a custom route
 

pages/vpc/reference-content/understanding-nacls.mdx

@@ -48,18 +48,18 @@ When defining a NACL rule, you must enter the following settings:
 - **Protocol**: Either `TCP`, `UDP`, or `ICMP`. The rule will apply only to traffic matching this protocol. Alternatively, you can choose to apply it to traffic matching any protocol.
 
 - **Source** and **destination**: The rule will apply to traffic originating from this source and being sent to this destination. For both, enter an IP range in [CIDR format](/vpc/concepts/#cidr-block), and a port or port range. Alternatively, you can opt for the rule to apply to all IPs and/or all ports.
-    
+
 - **Action**: The NACL will either **Allow** (accept) or **Deny** (drop) traffic that matches the rule.
 
 ## Rule priority and application
 
-The Network Access Control List should be read from top to bottom. Rules closer to the top of the list are applied first. If traffic matches a rule for an **Allow** or **Deny** action, the action is applied immediately. That traffic is not then subject to any further filtering or any further actions by any rules that follow. 
+The Network Access Control List should be read from top to bottom. Rules closer to the top of the list are applied first. If traffic matches a rule for an **Allow** or **Deny** action, the action is applied immediately. That traffic is not then subject to any further filtering or any further actions by any rules that follow.
 
 ## Statelessness
 
 **NACL rules are stateless**. This means the state of connections is not tracked, and inbound and outbound traffic is filtered separately. Return traffic is not automatically allowed just because the outbound request was allowed. Explicit rules are required for each direction of traffic.
 
-Therefore, if you create a rule to allow traffic in one direction, you may also need a separate rule to allow the response in the opposite direction. 
+Therefore, if you create a rule to allow traffic in one direction, you may also need a separate rule to allow the response in the opposite direction.
 
 ## Default rule
 
@@ -75,7 +75,7 @@ The table below shows an example of a NACL for IPv4 traffic:
 
 <Lightbox image={image3} alt="A table shows a number of NACL rules" />
 
-- A number of TCP rules allow connections to the specific ports necessary for SSH, HTTP, and HTTPS traffic. These rules allow all IPv4 sources within the VPC to connect to these ports, for all IPv4 destinations. 
+- A number of TCP rules allow connections to the specific ports necessary for SSH, HTTP, and HTTPS traffic. These rules allow all IPv4 sources within the VPC to connect to these ports, for all IPv4 destinations.
 
 - An ICMP rule allows all ICMP traffic from/to all IPv4 addresses on all ports, effectively permitting all ping requests within the VPC to function.
 
@@ -93,9 +93,9 @@ Network ACLs cannot be used to block or filter the traffic to or from the follow
 - Scaleway DHCP
 - Scaleway Instance metadata
 - Kubernetes Kapsule task metadata endpoints
-- License activation for Windows installation on Elastic Metal or Instances 
+- License activation for Windows installation on Elastic Metal or Instances
 
-NACLs have the same resource limitations as [VPC routing](/vpc/reference-content/understanding-routing/#limitations), they cannot currently be used to filter Managed Database traffic, though this functionality is planned for the future.
+NACLs have the same resource limitations as [VPC routing](/vpc/reference-content/understanding-routing/#limitations).
 
 NACLs are currently available only via the Scaleway API and developer tools. They are not yet available in the Scaleway console.
 
@@ -104,4 +104,4 @@ NACLs are currently available only via the Scaleway API and developer tools. The
 NACL quotas are as follows:
 
 - A maximum of 255 rules for IPv4 (per VPC)
-- A maximum of 255 rules for IPv6 (per VPC)
+- A maximum of 255 rules for IPv6 (per VPC)

pages/vpc/reference-content/understanding-routing.mdx

@@ -23,7 +23,7 @@ You can create your own custom routes to send traffic for defined IP ranges towa
 
 Routing is activated by default whenever you create a new VPC, and can be activated on pre-existing VPCs by [following these steps](/vpc/how-to/manage-routing/#how-to-activate-routing). Network ACLs, to finely control and filter VPC traffic, are available [via the API](/vpc/reference-content/understanding-nacls) (currently in Public Beta).
 
-The diagram below shows an example of how routing works across two Private Networks on a VPC. The route table is held on the VPC's virtual router ([VRouter](/vpc/concepts/#vrouter)), and synched to each resource as it joins a Private Network. 
+The diagram below shows an example of how routing works across two Private Networks on a VPC. The route table is held on the VPC's virtual router ([VRouter](/vpc/concepts/#vrouter)), and synched to each resource as it joins a Private Network.
 - An Elastic Metal server on Private Network A can send a packet to the public internet via a Public Gateway also attached to Private Network A.
 - An Instance also on Private Network A can send a packet to an Instance on Private Network B, via the vRouter.
 - The same Instance on Private Network A can send a packet to an IP destination at the other end of the VPN hosted on Instance XYZ on Private Network B, thanks to a custom route.
@@ -37,7 +37,7 @@ The diagram below shows an example of how routing works across two Private Netwo
 Every VPC has an associated **route table**, used to manage and control the routing of traffic within the VPC. The routes within a route table tell the VPC where to send traffic trying to get to a specific destination IP address. One line in the route table corresponds to one route. A route consists of:
 
 - A **destination** IP or IP range. This specifies that the route applies to traffic with a matching destination IP.
-- A **next hop**. This specifies where the VPC should forward traffic that is trying to reach the destination IP. 
+- A **next hop**. This specifies where the VPC should forward traffic that is trying to reach the destination IP.
     - For local subnet routes, the next hop will be the relevant Private Network. Traffic destined for an IP within the CIDR block of the Private Network's subnet will find the attached resource there.
     - For custom routes, the next hop is a defined resource on a defined Private Network.
     - If the destination IP is not known on the VPC (represented by the `0.0.0.0/0` address), its next hop will be a Public Gateway so that it can reach the public internet (as long as a Public Gateway set to advertise the default route has been attached to the Private Network).
@@ -156,5 +156,5 @@ Alternatively, and aligned with best practice, when the default NACL rule **Deni
 
 ## Limitations
 
-- Managed Databases are not currently compatible with routing. The VPC cannot automatically route between Managed Databases on different Private Networks, or (for example) between a Managed Database on one Private Network and an Instance on a different Private Network.
-- VPC routing does not currently support virtual IPs.
+- Only Managed PostgreSQL and MySQL Database Instances created after July 28th 2025 are compatible with VPC routing. Maintenance scheduled for later in August 2025 will make all pre-existing Managed PostgreSQL and MySQL Database Instances compatible as well.
+- VPC routing does not currently support virtual IPs.

pages/vpc/troubleshooting/vpc-limitations.mdx

@@ -22,4 +22,5 @@ This page sets out some current limitations of Scaleway's VPC.
   - Kubernetes Kapsule (only during the process of creating the Kapsule cluster)
   - Serverless Functions and Containers (egress traffic only, with VPC-supporting namespaces)
 - Private Networks are not supported on some legacy Instance offers which have reached EOL, e.g. `VC1`, `START1` and `X64-*GB`. Note that all Instance offers in the [current product catalogue](https://www.scaleway.com/en/pricing/?tags=compute) are supported.
-- Managed Databases are not currently compatible with VPC routing. The VPC cannot automatically route between Managed Databases on different Private Networks, or (for example) between a Managed Database on one Private Network and an Instance on a different Private Network.
+- Only Managed PostgreSQL and MySQL Database Instances created after July 28th 2025 are compatible with [VPC routing](/vpc/concepts/#routing). Maintenance scheduled for later in August 2025 will make all pre-existing Managed PostgreSQL and MySQL Database Instances compatible as well. 
+