Focused by design
XLB keeps the product centered on extreme-scale TCP backend selection and packet routing.
XLB vs LoxiLB
A focused fast path instead of a broad networking stack.
XLB and LoxiLB both bring eBPF to cloud-native load balancing. LoxiLB spans a wide networking feature set across protocols, routing, ingress, and telco use cases. XLB concentrates on one outcome: the fastest, easiest, and most cost-effective IPv4 and TCP load-balancing tier for millions of requests per second.
Focused IPv4 and TCPCompletely tuning freeCommercially supported
Why teams choose XLB
A better load-balancing tier at serious scale.
Feature breadth and product focus lead to different operating models. LoxiLB covers a large cloud-native networking surface. XLB intentionally narrows the surface so teams can deploy a high-performance TCP load balancer with fewer decisions and less maintenance.
Minimal operations
One product, basic configuration, automatic backend updates, built-in monitoring, and no tuning cycle to maintain.
A supported outcome
XLB includes commercial evaluation, deployment assistance, and ongoing support under a flat negotiated license.
| What matters | LoxiLB | XLB |
|---|---|---|
| Design goal | Broad cloud-native load balancing, routing, ingress, and networking capabilities | Highest-performance, lowest-maintenance IPv4 and TCP load balancing |
| eBPF role | Data path for a multi-feature networking stack | Focused XDP fast path for backend selection and packet rewriting |
| Protocol scope | TCP, UDP, SCTP, QUIC and additional networking modes | IPv4 and TCP NAT, optimized deeply for the core target workload |
| Feature scope | L4 and L7 functions, ingress, Gateway API, BGP, NAT variants, DSR, and telco features | Extreme-scale L4 balancing, discovery, monitoring, autoscaling signals, and support |
| Product components | Go control plane, eBPF data path, goBGP, Kubernetes operator, and ingress components | Independent XLB instances with local configuration and backend state |
| Configuration | Configuration depends on the networking capabilities deployed | Listener plus static backends or one Kubernetes Service reference |
| Tuning | Architecture and feature configuration depend on deployment goals | Completely tuning free |
| Observability | Prometheus, logs, and integrations in the LoxiLB ecosystem | Built-in console plus premade Grafana and Datadog configurations through OpenTelemetry |
| Product model | Apache 2.0 open source project | Flat negotiated commercial license with deployment and ongoing support |
Product focus matters
Optimize for the job you actually need done.
Using eBPF does not make two products identical. Architecture, feature surface, and operating model determine what your team deploys and maintains. XLB turns a narrow product scope into a straightforward commercial promise: maximum L4 performance without a tuning project.
A shorter decision list
Choose a listener and backend source. XLB avoids making the operator assemble a broader routing, ingress, or network-service architecture.
A consistent operating model
The same focused product runs across Kubernetes, bare metal, and virtual machines, with local status and OpenTelemetry export.
Commercial accountability
Neuronic helps validate the workload, deploy XLB, and support the production result under a negotiated agreement.
Common questions
XLB and LoxiLB.
Are both XLB and LoxiLB based on eBPF?
Yes. Both use eBPF in the Linux networking data path. The product focus differs. LoxiLB combines a broad cloud-native networking and load-balancing feature set. XLB is deliberately focused on maximum IPv4 and TCP load-balancing performance, minimal configuration, and low operating cost.
Why choose XLB instead of a broader eBPF load balancer?
Choose XLB when the main requirement is moving very large TCP traffic volumes with the smallest practical server footprint and operational surface. XLB has no application-specific tuning, automatic Kubernetes Ready Pod discovery, built-in monitoring, and commercial deployment support.
Does XLB support Kubernetes autoscaling and monitoring?
Yes. XLB exports CPU and network utilization that can drive Kubernetes autoscaling across multiple instances. It includes a built-in console and premade Grafana and Datadog configurations through OpenTelemetry for cluster-wide monitoring.
Is XLB open source?
XLB is a commercial product with a flat negotiated license. The agreement includes the deployment and support terms appropriate to the customer. The license is not metered by requests, connections, bytes, or traffic volume.
Official product references
Competitor details on this page are based on the vendor’s own documentation.
Prove it with your workload
See what your load balancer could cost.
Bring your current topology, traffic profile, or cloud bill. We’ll scope a representative XLB evaluation.