scaleway · ldecarvalho-doc · Jun 5, 2025 · Jun 5, 2025 · Jun 9, 2025
@@ -22,6 +22,11 @@ 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.
 
+<Message type="note">
+  Managed Databases for PostgreSQL and MySQL is compatible with the [VPC routing](/vpc/concepts/#routing) feature, which allows you to connect one or more Database Instances in Private Network to resources in other Private Networks of the same VPC. Refer to the [How to manage routing](/vpc/how-to/manage-routing/) documentation page for more information.
+</Message>
+
+
 <Macro id="requirements" />
 
 - A Scaleway account logged into the [console](https://console.scaleway.com)
@@ -31,9 +36,9 @@ You can create new Database Instances to attach to your Private Network, or atta
 
 ## 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.

@@ -40,10 +40,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.

@@ -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/).
 
 <Macro id="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:
 Two types of auto-generated routes exist:
 
 - **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">
 Public Gateways remain scoped to the Private Network(s) to which they are attached. They do not advertise the default route on other Private Networks in the VPC. For example, an Instance attached to Private Network A will not be able to access the internet via a Public Gateway in Private Network B.
@@ -64,17 +64,17 @@ 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 src="scaleway-route-table.webp" alt="" />
 
     For help with understanding the route table and how to read it, [refer to our documentation about route tables](/vpc/reference-content/understanding-routing/#route-table).
 
-### 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.
 
@@ -110,7 +110,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: **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">
@@ -123,15 +123,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 src="scaleway-route-not-found.webp" 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
 

@@ -50,18 +50,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, to proceed to its destination.
 
 ## 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
 
@@ -77,7 +77,7 @@ The table below shows an example of a NACL for IPv4 traffic:
 
 <Lightbox src="scaleway-nacl-example.webp" 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.
 
@@ -95,9 +95,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.
 

@@ -25,7 +25,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). More routing features are planned for the future, such as ACLs and firewalling.
 
-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.
@@ -39,7 +39,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).
@@ -79,5 +79,4 @@ For example, you may use one Private Network for frontend resources and another
 
 ## 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.
@@ -27,4 +27,4 @@ This page sets out some current limitations of Scaleway's VPC.
   - Managed Databases for Redis™ (only during the process of creating the database)
   - Kubernetes Kapsule (only during the process of creating the Kapsule cluster)
 - 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.
+
@@ -17,10 +17,6 @@ You may have problems with connectivity between resources in a VPC or Private Ne
 
 This page helps you solve potential errors that are related to VPC connectivity and routing.
 
-## My Managed Database cannot communicate with other resources in my VPC
-
-This is normal, as VPC routing is not yet supported by Managed Databases for PostgreSQL and MySQL, nor Managed Databases for Redis. Adding support for Managed Databases is planned for the future.
-
 ## I cannot deactivate routing on my VPC
 
 This is standard behavior: