only if it was so simple. you can set up routing restrictions between subnets on the IP level, but the switch will gladly forward all traffic anywhere inside of the VLAN, according to the destination MAC address. with that, a compromised system can confuse every other on the VLAN with ARP poisoning and faking DHCP servers.

This is what private VLAN's fix. The switch isolates all traffic, forwarding it to the firewall instead, where the firewall can then monitor and control it. It's usually done with a combination of port isolation, where layer2 traffic within a subnet is essentially blocked, and proxying the arp requests. Nothing can communicate with each other directly at the Layer 2 level, only with the switch, which then replies to all ARP requests instead. Then the switch forwards the traffic that was supposed to go to that IP address through the firewall and back as Layer 3 traffic.

with that, a compromised system can confuse every other on the VLAN with ARP poisoning and faking DHCP servers.

This is what Private VlAN's fix. Any ARP requests a device attempts is simply blocked at the switch level via port isolation. Only the switch is able to communicate with attached devices unrestricted. It serves the DHCP, and assigns and IP address... and then if the device attached to the port attempts to lie about it's IP address or the like, the switch simply ignores it since it knows what ports are supposed to have what IP addresses (port security).

This allows for much more granular isolation, but also a simpler architecture, since you can replace complex multi VLAN setups with fewer private VLAN's. Maybe even just a single private VLAN. I say VLAN's suck because by default, yeah they kinda suck. You pointed out the problems. I guess private VLAN's are a type of VLAN but they are a different thing, just like not having any VLAN's is really technically just one big VLAN.

yeah, that’s the easier part. but one of the databases is mysql, which I want to get rid of completely. and conversion is nontrivial. probably dbveaver could handle it though.

Is it a custom service? Or a service you are consuming from someone else? If the services supports mysql/maria/postgres, I would be worried that the adapter under the hood might be using different schema or something like that.

It does look like dbeaver has a data transfer feature: https://dbeaver.com/docs/dbeaver/Data-transfer/#supported-formats

Where you can transfer data across tables, across databases, and even across database types. There is also "Data export" mentioned on that page, where you can export data to json, or other non sql formats. If the schema match, maybe you could use that to transfer.

If the services supports both mysql and postgres, you might be able to start by making a backup of the mysql database, loading that into a test database, and then setting up a clone of the service, but pointed at postgres instead. Then you could investigate the schema, or safely attempt data transfer from the mysql replica into the postgres database. Or mariadb, but mariadb is compatible with mysql (fork of it), so I am assuming you meant postgres which is different.