fix(rdb): remove mentions of db in vpc

Author: ldecarvalho-doc

pages/vpc/faq.mdx

@@ -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.

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/).
 
 <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
 

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

@@ -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.
 

pages/vpc/troubleshooting/vpc-limitations.mdx

@@ -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.
+

pages/vpc/troubleshooting/vpc-pn-routing-connectivity-issues.mdx

@@ -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: