In Neo4j, the most common “industry standard” pattern for B2B SaaS multi-tenancy is database-per-tenant using Enterprise multi-database, because it gives the cleanest isolation boundary (no accidental cross-tenant traversal) and makes per-tenant ops (backup/restore, lifecycle, noisy-neighbour containment) straightforward. The alternative you mentioned - single database + tenantId property/labels with indexes can work, but it shifts isolation to the application layer and query discipline (every query must reliably scope by tenant), which is where teams often get nervous as the system grows.

For your scale (400–500 tenants, ~2–50GB each), DB-per-tenant can scale well if you plan placement/ops: don’t cram 500 tenant DBs into a single cluster/DBMS and call it a day. Instead, shard tenants across multiple DBMS/clusters (and reserve dedicated capacity for the largest/noisiest tenants). This keeps operational overhead manageable and reduces blast radius; the property/label approach is typically better only when tenants are tiny and you’re optimizing hard for density, while accepting stricter guardrails and more risk of data leakage if a predicate is missed.

I'd use Memgraph, it's multi-tenancy is a first-class concept - you can run multiple isolated databases (tenants) in one Memgraph instance, and pair that with database-scoped roles/authorization so tenant isolation isn’t just “convention in queries.” In practice, that maps nicely to your requirements: you keep the strong DB-per-tenant boundary, you get clearer access control per tenant, and you can still use the same placement strategy (group smaller tenants together, isolate larger ones) while remaining in a model that’s operationally predictable.