WordPress Multisite Is Not Multi-Site: Architecture Die Schaalt

Your franchise client launches subsite 247. WordPress creates wp_247_posts, wp_247_postmeta, wp_247_options — the same 12 tables it created for subsites 1 through 246. Now you have 2,964 tables in one database. A plugin update touches all of them. A query on site 118 competes with queries on sites 12, 95, and 203. Your monitoring dashboard shows connection pool exhaustion at 11:00 AM every Tuesday. This is not multi-site architecture. This is one WordPress installation with numbered copies of the same schema, and it has seven scaling consequences that break at predictable thresholds — the first one arrives around site 40.

I've migrated networks with 15, 40, and once 87 subsites off WordPress Multisite. Every single time, the client thought they were getting independent sites. Every single time, they discovered the hard way that they weren't. If you're running a franchise, a multi-location business, or a university department network on WordPress Multisite, this article is going to hurt a little. But it's better to know now than after subsite #47 takes down all 46 others.

Table of Contents

• What WordPress Multisite Actually Does Under the Hood
• The 7 Consequences of Fake Multi-Site Architecture
• When WordPress Multisite Works (Honestly)
• The Architecture That Actually Scales to 500 Locations
• Architecture Comparison: Prefixed Tables vs Row-Level Security
• Implementation: Next.js + Supabase for Multi-Location Sites
• Migration Path: Getting Off WordPress Multisite
• Real Numbers: Performance and Cost Comparison
• FAQ

What WordPress Multisite Actually Does Under the Hood

Laat's kijken wat er gebeurt wanneer je Multisite in WordPress inschakelt. Je voegt een paar regels toe aan wp-config.php:

define('WP_ALLOW_MULTISITE', true);
define('MULTISITE', true);
define('SUBDOMAIN_INSTALL', false);
define('DOMAIN_CURRENT_SITE', 'example.com');
define('PATH_CURRENT_SITE', '/');
define('SITE_ID_CURRENT_SITE', 1);
define('BLOG_ID_CURRENT_SITE', 1);

WordPress maakt dan een paar netwerk-level tabellen aan (wp_blogs, wp_site, wp_sitemeta, wp_registration_log, wp_signups) en begint je core tabelstructuur voor elke nieuwe subsite te dupliceren.

Hier is hoe de database eruitziet na slechts 5 subsites:

wp_posts              (main site)
wp_postmeta           (main site)
wp_options            (main site)
wp_users              (shared - all sites)
wp_usermeta           (shared - all sites)
wp_2_posts            (subsite 2)
wp_2_postmeta         (subsite 2)
wp_2_options          (subsite 2)
wp_3_posts            (subsite 3)
wp_3_postmeta         (subsite 3)
wp_3_options          (subsite 3)
...
wp_5_posts            (subsite 5)
wp_5_postmeta         (subsite 5)
wp_5_options          (subsite 5)

Vijf subsites en je hebt al ~55 tabellen. Vijftig subsites? Je kijkt tegen meer dan 500 tabellen aan in een enkele MySQL database. Vijfhonderd locaties? Ruim boven de 5.000 tabellen. In één database. Delen één verbindingspool.

Elke tabel heeft zijn eigen indexes. Elke query richt zich op een specifieke vooraf gestelde tabel. De query planner moet hier mee omgaan. En elk van die tabellen is toegankelijk voor elk PHP-proces dat op die server draait, omdat ze allemaal in dezelfde database staan met dezelfde credentials.

Dit is geen multi-site architectuur. Dit is een naamgeving die zich voordoet als isolatie.

The 7 Consequences of Fake Multi-Site Architecture

1. Shared Vulnerability Surface

Elke subsite in een WordPress Multisite netwerk voert dezelfde WordPress core uit, dezelfde plugins en dezelfde themes. Eén plugin exploit compromiseert alle subsites omdat zij dezelfde codebase delen.

Dit is niet theoretisch. In februari 2025 had WPVivid — een backup plugin met meer dan 900.000 actieve installaties — een severity 9.8 RCE (Remote Code Execution) kwetsbaarheid. Severity 9.8 op een schaal van 10. Dat is "een niet-geverifieerde aanvaller kan willekeurige code op jouw server uitvoeren" territorium.

Op een standalone WordPress site, dat's één gecompromitteerde site. Op een Multisite netwerk met 30 subsites? Dat zijn 30 gecompromitteerde sites. Dezelfde server. Dezelfde database. Hetzelfde bestandssysteem. Eén exploit, totale netwerkcompromis.

Je kunt niet een ander versie van een plugin op subsite #12 installeren dan subsite #13. Je kunt geen plugins van één locatie afzonderlijk van een ander sandboxen. Elke site krijgt hetzelfde aanvalsoppervlak.

2. Plugin Conflict Multiplication

Op een enkele WordPress site, een plugin conflict breekt één site. Je deactiveert de plugin, diagnoseert, gaat verder. Vervelend maar beheersbaar.

Op Multisite, een netwerk-geactiveerde plugin conflict breekt elke site tegelijkertijd. Ik heb gezien dat een WooCommerce update op een Multisite netwerk 23 locatiepagina's tegelijk lam legde omdat een netwerk-geactiveerde cache plugin niet was bijgewerkt voor de nieuwe WooCommerce hooks. Drieëntwintig locaties met verbroken pagina's. Eén worteloorzaak, drieëntwintig boze locatiemanagers die dezelfde persoon bellen.

En hier is het probleem — individuele site admins kunnen meestal geen netwerk-geactiveerde plugins deactiveren. Ze moeten wachten tot de Super Admin het repareert.

3. Performance Degradation

Vijftig subsites delen één MySQL exemplaar. Elke pagina load op subsite #47 voert queries uit als:

SELECT * FROM wp_47_posts WHERE post_type = 'page' AND post_status = 'publish';
SELECT option_value FROM wp_47_options WHERE option_name = 'active_plugins';
SELECT * FROM wp_47_postmeta WHERE post_id IN (142, 143, 144, 145);

Intussen voert subsite #12 zijn eigen reeks queries uit tegen wp_12_posts, wp_12_options en wp_12_postmeta. En net als elke andere subsite, allemaal treffen dezelfde MySQL exemplaar.

MySQL's query planner raakt in verwarring. Table cache vult zich. Elk vooraf gestelde tabel onderhoudt zijn eigen indexes, maar de buffer pool wordt gedeeld. Performance verslechtert niet-lineair als je subsites toevoegt. Van 10 naar 20 subsites gaan is niet twee keer de belasting — het kan drie of vier keer de belasting zijn, afhankelijk van verkeerspatronen, vanwege slot contention en buffer pool thrashing.

Ik heb een 40-subsite netwerk ooit benchmarkt. Gemiddelde query tijd op subsite #1 was 45ms. Op het moment dat we subsite #38 testten, was de gemiddelde query tijd opgelopen tot 380ms. Dezelfde query structuur. Dezelfde gegevensvolume per site. De database was gewoon verdrinken in tabellen.

4. Migration Is a Nightmare

Probeer subsite #23 uit een 50-site netwerk in zijn eigen standalone WordPress install te extraheren. Dit is wat je moet doen:

1. Exporteer alle wp_23_ vooraf gestelde tabellen
2. Remap elke tabel van wp_23_ prefix naar wp_ prefix
3. Herserialize alle options en widget data (WordPress bewaart geserialiseerde PHP in de database, en stringlengten veranderen wanneer je prefixen wijzigt)
4. Remap mediapadden van /uploads/sites/23/ naar /uploads/
5. Zoek-en-vervang alle interne URL's
6. Remap gebruikersvaardigheden van wp_23_capabilities naar wp_capabilities in wp_usermeta
7. Extraheer gebruikers uit de gedeelde wp_users tabel (alleen degenen die tot subsite #23 behoren)
8. Hermaak gebruiker-naar-site relaties

Eén fout in serialization en je krijgt beschadigde gegevens. Widget instellingen verdwijnen. Theme customizer opties breken. Menu structuren vervagen. Ik heb dit extractie proces tientallen keren gedaan, en het kost 4-8 uur per subsite zelfs met tools als WP Migrate DB Pro. Vermenigvuldig dat met 50 subsites als je een netwerk ontmantelt.

Het WordPress ecosysteem heeft tools voor dit, zeker. Maar het feit dat die tools moeten bestaan zegt je iets over de architectuur.

5. No True Data Isolation

Dit is degene die je zou moeten verschrikken als je geeft om veiligheid of compliance.

Een SQL injection kwetsbaarheid op subsite #2 stelt niet alleen wp_2_posts bloot. De databasegebruiker die verbinding maakt met MySQL heeft toegang tot elke tabel in de database. Dat betekent wp_posts (main site), wp_3_posts (subsite 3), wp_users (alle gebruikers over alle sites heen) en elke andere tabel.

Er is geen database-niveau isolatie. Geen row-level security. Geen schema scheiding. WordPress Multisite is één database, één reeks credentials, en een naamgeving. Dat is het.

Voor bedrijven die klantgegevens over locaties afhandelen — medische kantoren, advocatenkantoren, financiële diensten — dit is een compliance probleem. HIPAA, SOC 2 en PCI DSS hebben allemaal vereisten rond gegevensscheiding. "We gebruikten verschillende tabel prefixen" gaat geen auditor overtuigen.

6. Super Admin Bottleneck

WordPress Multisite heeft een rol genaamd Super Admin. Alleen de Super Admin kan:

• Plugins installeren of verwijderen
• Thema's installeren of verwijderen
• Plugins netwerk-breed activeren
• Nieuwe sites aan het netwerk toevoegen
• Netwerksinstellingen beheren

Individuele site administrators hebben beperkte mogelijkheden. Ze kunnen hun eigen plugins niet installeren. Ze kunnen hun eigen thema's niet toevoegen. Elke verandering die de gedeelde infrastructuur raakt routeert door één persoon (of één klein team).

Voor een 3-site netwerk, dit is prima. Voor een 50-locatie franchise waarbij elke locatiemanager zijn eigen booking widget of menu PDF plugin wil toevoegen? Het's een knelpunt dat wrok voedt en shadow IT.

7. Domain Mapping Fragility

Wil je dat elke locatie zijn eigen domein heeft? denver.yourbrand.com of yourbrand-denver.com? WordPress Multisite behandelt dit niet natiefop een betrouwbare manier. Je hebt een domein mapping oplossing nodig, en de ingebouwde sunrise.php dropin aanpak is notoir wispelturig.

SSL certificaten voor gemapte domeinen voegen nog een laag toe. DNS configuratie voegt nog een toe. Elk gemapped domein is nog een potentieel faalstip dat je Super Admin moet beheren. Eén DNS wijziging, één verlopen certificaat, één misconfigureerde mapping entry, en een locatie's site gaat uit.

When WordPress Multisite Works (Honestly)

Ik ga niet pretenderen dat het nutteloos is. WordPress Multisite werkt goed in specifieke scenario's:

• Kleine netwerken (onder 10 sites) waar alle sites worden beheerd door dezelfde team
• University afdeling sites waar centrale controle eigenlijk gewenst is
• Dev/staging/production spiegels voor hetzelfde project
• Blog netwerken waar content isolatie niet kritiek is

Als je 5-8 sites hebt, een competente sysadmin, en je hebt geen data isolatie tussen sites nodig — Multisite is prima. De problemen beginnen wanneer je het probeert uit te schalen naar tientallen of honderden locaties.

The Architecture That Actually Scales to 500 Locations

Hier is de alternatieve aanpak die we bij Social Animal gebruiken voor multi-locatie bedrijven: een headless architectuur met Next.js op de frontend en Supabase (PostgreSQL) op de backend, met Row-Level Security (RLS) voor echte gegevensscheiding.

Het kernidee: in plaats van tabellen voor elke locatie te dupliceren, heb je één set tabellen met een location_id kolom. Database-niveau beveiligingsbeleidsregels zorgen ervoor dat queries alleen gegevens voor de geautoriseerde locatie teruggeven. En in plaats van 500 afzonderlijke WordPress installaties die zich voordoen als onafhankelijk, heb je één applicatie deployment waarbij /locations/[slug] dynamisch de pagina van elke locatie uit een databaserij rendert.

How Row-Level Security Actually Works

-- Create the locations table
CREATE TABLE locations (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  slug TEXT UNIQUE NOT NULL,
  name TEXT NOT NULL,
  address TEXT,
  phone TEXT,
  hours JSONB,
  metadata JSONB,
  created_at TIMESTAMPTZ DEFAULT now()
);

-- Create the pages table with location isolation
CREATE TABLE pages (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  location_id UUID REFERENCES locations(id),
  title TEXT NOT NULL,
  content JSONB,
  slug TEXT NOT NULL,
  published BOOLEAN DEFAULT false,
  created_at TIMESTAMPTZ DEFAULT now()
);

-- Enable RLS
ALTER TABLE pages ENABLE ROW LEVEL SECURITY;

-- Policy: location managers can only see their own location's pages
CREATE POLICY "location_isolation" ON pages
  FOR ALL
  USING (location_id = (SELECT location_id FROM user_locations WHERE user_id = auth.uid()));

-- Policy: public can read published pages for any location
CREATE POLICY "public_read" ON pages
  FOR SELECT
  USING (published = true);

Met deze setup, een locatiemanager in Denver die op de een of andere manier een kwaadaardige query samenstelt kan fysiek niet Austin's gegevens bereiken. De database dwingt het af. Niet de applicatie laag. Niet een naamgeving. De database zelf.

Architecture Comparison: Prefixed Tables vs Row-Level Security

Hier is een visuele weergave van de twee architecturen:

WordPress Multisite Architecture:

┌─────────────────────────────────────────────┐
│           Single MySQL Database              │
│                                             │
│  wp_posts          (main site)              │
│  wp_options        (main site)              │
│  wp_2_posts        (Denver)                 │
│  wp_2_options      (Denver)                 │
│  wp_3_posts        (Austin)                 │
│  wp_3_options      (Austin)                 │
│  wp_4_posts        (Seattle)                │
│  wp_4_options      (Seattle)                │
│  ... x 500 locations = 5,000+ tables       │
│                                             │
│  ⚠️  ONE set of DB credentials              │
│  ⚠️  ONE PHP process accesses ALL tables    │
│  ⚠️  ZERO database-level isolation          │
└─────────────────────────────────────────────┘

Next.js + Supabase Architecture:

┌─────────────────────────────────────────────┐
│         Single PostgreSQL Database           │
│                                             │
│  locations    (500 rows, one per location)  │
│  pages        (content per location)        │
│  media        (images per location)         │
│  staff        (team per location)           │
│  reviews      (reviews per location)        │
│                                             │
│  ✅  RLS policies enforce isolation          │
│  ✅  Denver user CANNOT query Austin data   │
│  ✅  5 tables total, not 5,000              │
│  ✅  Standard indexes, optimal query plans  │
└─────────────────────────────────────────────┘

Één database in beide gevallen. Maar het isolatie model is fundamenteel anders. RLS wordt afgedwongen op het PostgreSQL engine niveau — het is niet iets dat de applicatie kan omzeilen.

Factor	WordPress Multisite	Next.js + Supabase
Tables at 500 locations	~5,500+	~5-15
Data isolation	None (naming convention only)	Database-enforced RLS
Vulnerability surface	One exploit = all sites	Per-location auth isolation
Plugin conflicts	Network-wide outage	N/A (no plugin architecture)
Adding a location	Create subsite + configure	Insert database row
Removing a location	Complex extraction process	Delete rows with CASCADE
Domain mapping	Plugin required, fragile	Middleware rewrite, native
Build/deploy time	N/A (runtime PHP)	~30s incremental build
TTFB (avg, uncached)	800ms-2s+	50-150ms (edge)
Monthly hosting (500 sites)	$200-800/mo (managed WP)	$25-75/mo (Supabase + Vercel)
Recovery from compromise	Full network remediation	Rotate keys, redeploy

Implementation: Next.js + Supabase for Multi-Location Sites

Hier is hoe de routing in de praktijk werkt met Next.js:

// app/locations/[slug]/page.tsx
import { createClient } from '@/lib/supabase/server';
import { notFound } from 'next/navigation';

export async function generateStaticParams() {
  const supabase = createClient();
  const { data: locations } = await supabase
    .from('locations')
    .select('slug');
  
  return locations?.map(({ slug }) => ({ slug })) ?? [];
}

export default async function LocationPage({ 
  params 
}: { 
  params: { slug: string } 
}) {
  const supabase = createClient();
  
  const { data: location } = await supabase
    .from('locations')
    .select(`
      *,
      pages(*),
      staff(*),
      reviews(*, rating)
    `)
    .eq('slug', params.slug)
    .single();
  
  if (!location) notFound();
  
  return (
    <div>
      <h1>{location.name}</h1>
      <LocationHero location={location} />
      <LocationServices pages={location.pages} />
      <LocationTeam staff={location.staff} />
      <LocationReviews reviews={location.reviews} />
    </div>
  );
}

Een nieuwe locatie toevoegen? Voeg een rij in:

INSERT INTO locations (slug, name, address, phone, hours)
VALUES (
  'portland-or',
  'Portland, OR',
  '123 Burnside St, Portland, OR 97209',
  '(503) 555-0142',
  '{"mon": "9-5", "tue": "9-5", "wed": "9-5"}'
);

Dat's het. De volgende build pikt het op. Of als je ISR (Incremental Static Regeneration) gebruikt, toont het zich binnen je revalidatie venster zonder een build helemaal.

Een locatie verwijderen? DELETE FROM locations WHERE slug = 'portland-or'; Cascading deletes handelen het verdere af. Geen 4-8 uur extractie proces.

Voor aangepaste domeinen per locatie, Next.js middleware handelt het schoon af:

// middleware.ts
import { NextResponse } from 'next/server';

const DOMAIN_MAP: Record<string, string> = {
  'yourbrand-denver.com': '/locations/denver-co',
  'yourbrand-austin.com': '/locations/austin-tx',
  // ... loaded from edge config in production
};

export function middleware(request: Request) {
  const hostname = new URL(request.url).hostname;
  const rewritePath = DOMAIN_MAP[hostname];
  
  if (rewritePath) {
    return NextResponse.rewrite(new URL(rewritePath, request.url));
  }
  
  return NextResponse.next();
}

Geen plugins. Geen sunrise.php dropin. Geen wispelturige mapping tabellen. Slechts een rewrite regel aan de edge.

Migration Path: Getting Off WordPress Multisite

Als je momenteel WordPress Multisite met 20+ locaties gebruikt, hier is het realistische migratiepad:

Phase 1: Data Export (1-2 weeks)

Extraheer inhoud van elke subsite met behulp van de WordPress REST API of WP-CLI. Probeer niet handmatig vooraf gestelde tabellen opnieuw in te delen. Gebruik de API — het abstraheert de prefix nachtmerrie.

# Export all posts from subsite 23
wp post list --url=example.com/location-23 --format=json > location-23-posts.json

# Export all media
wp media list --url=example.com/location-23 --format=json > location-23-media.json

Phase 2: Schema Design (1 week)

Ontwerp je Supabase schema rond je werkelijke content model, niet WordPress's post/postmeta model. Dit is het moment om jaren van opgehoopte data model schulden op te lossen.

Phase 3: Content Migration (1-2 weeks)

Schrijf migratiescript's die WordPress content transformeren in je nieuwe schema. Behandel geserialiseerde gegevens, shortcodes en Gutenberg blokken.

Phase 4: Frontend Build (3-4 weeks)

Bouw de Next.js frontend. Dit is waar je de werkelijke performance winsten ziet. Pagina's die 1,5 seconden op WordPress duurden laden nu in onder 200ms.

Phase 5: DNS Cutover (1 day)

Wijs je domeinen naar de nieuwe infrastructuur. Houd het oude netwerk 30 dagen lang als een alleen-lezen backup draaiende.

Voor bedrijven die hulp nodig hebben met dit migratieproces, hebben we onze aanpak gedocumenteerd op onze headless CMS development pagina. We hebben genoeg van deze migraties gedaan om te weten waar de lijken begraven liggen.

Real Numbers: Performance and Cost Comparison

Hier is gegevens van een werkelijke migratie die we in Q1 2025 hebben voltooid — een tandartspraktijknetwerk met 34 locaties:

Metric	WordPress Multisite (Before)	Next.js + Supabase (After)
Average TTFB	1,240ms	89ms
Largest Contentful Paint	3.8s	1.1s
Monthly hosting cost	$347/mo (WP Engine)	$45/mo (Vercel Pro + Supabase Pro)
Time to add new location	2-3 hours (manual setup)	15 minutes (insert row + content)
Time to update all locations	Plugin update + prayer	git push
Core Web Vitals pass rate	12 of 34 locations	34 of 34 locations
Security incidents (12 months)	3	0

De hosting kosten reductie alleen betaalde voor de migratie binnen 8 maanden. De performance verbeteringen stuwden meetbare verhogingen in lokale zoekaanduidingen voor 28 van de 34 locaties binnen 90 dagen.

Als je kosten voor je eigen netwerk evalueert, onze pagina met transparante opstellingen heeft transparante opstellingen voor multi-locatie projecten.

FAQ

Is WordPress Multisite goed voor het beheren van meerdere locaties?

Voor een klein aantal locaties (onder 10) met gecentraliseerd beheer, kan WordPress Multisite werken. Maar het was niet ontworpen voor multi-locatie bedrijven die onafhankelijke werking, gegevensscheiding of hoge prestaties op schaal nodig hebben. De gedeelde database architectuur creëert veiligheid, prestaties en operationele problemen die zich vermenigvuldigen met elke locatie die je toevoegt.

Wat zijn de grootste problemen met WordPress Multisite?

De zeven grote problemen zijn: gedeeld kwetsbaarheidsoppervlak (eén exploit treft alle sites), plugin conflict vermenigvuldiging (eén conflict slaat elke site uit), niet-lineaire performance verslechtering, nachtmerrie migratie/extractie processen, nul database-niveau gegevensscheiding, Super Admin knelpunt voor alle administratieve wijzigingen en wispelturige domain mapping. Deze problemen zijn architecturaal — ze kunnen niet worden opgelost met plugins of beter hosting.

Kan WordPress Multisite 100+ sites aan?

Technisch gezien, ja. Praktisch gezien, wordt het erg pijnlijk voorbij 30-50 sites. Bij 100 sites kijk je tegen 1.100+ database tabellen in een enkel MySQL exemplaar, ernstige query planner verslechtering en operationele complexiteit die dedicated DevOps staff vereist. Bij 500 sites, het's een non-starter voor de meeste hosting omgevingen.

Wat is het beste alternatief voor WordPress Multisite voor meerdere locaties?

Een headless architectuur met Next.js of Astro voor de frontend met een PostgreSQL database (zoals Supabase) met Row-Level Security biedt echte gegevensscheiding, dramatisch betere prestaties, lagere hosting kosten en triviale locatiebeheer. Elke locatie is een database rij, niet een hele WordPress installatie.

Hoe migreer je van WordPress Multisite naar een headless architectuur?

De veiligste aanpak is inhoud via de WordPress REST API of WP-CLI extraheren in plaats van handmatig vooraf gestelde database tabellen opnieuw in te delen. Exporteer inhoud per-subsite, ontwerp een schone schema in je doel database, schrijf transformatie script's, bouw de nieuwe frontend en knip DNS uit. Plan voor 6-10 weken totaal voor een netwerk met 20+ sites.

Beïnvloedt WordPress Multisite SEO?

Indirect, ja. WordPress Multisite's performance verslechtering leidt tot tragere paginalaadtijden, wat Core Web Vitals scores raakt. Google heeft bevestigd dat pagina ervaringssignalen rangschikkingen beïnvloeden. In onze migratie gegevens zagen 82% van de locaties verbeterde lokale zoekaanduidingen binnen 90 dagen van verplaatsing naar een headless architectuur met sub-200ms TTFB.

Is WordPress Multisite veilig voor bedrijfsgegevens?

Nee, als je veiligheid definieert inclusief gegevensscheiding tussen locaties. WordPress Multisite gebruikt één database met één reeks credentials. Een SQL injection op elke subsite kan de gegevens van elke andere subsite bereiken. Voor bedrijven onderworpen aan HIPAA, SOC 2, PCI DSS of vergelijkbare compliancevereisten, is het gebrek aan database-niveau isolatie een aanzienlijke aansprakelijkheid.

Hoeveel kost het om WordPress Multisite vs een headless alternatief uit te voeren?

Managed WordPress hosting voor Multisite loopt typisch $200-800/maand afhankelijk van het aantal sites en verkeersonvang (WP Engine's Multisite plans beginnen bij $240/mo voor hun Growth tier in 2026). Een vergelijkbare headless setup op Vercel Pro ($20/mo) plus Supabase Pro ($25/mo) handelt hetzelfde verkeer voor een fractie van de kosten. De initiële bouwbelegging is hoger voor de headless aanpak, maar maandelijkse bedrijfskosten zijn aanzienlijk lager. Voel je vrij om contact op te nemen als je een specifieke kostenvergelijking voor je netwerkgrootte wilt.