Apache APISIX and Kong are the two most widely adopted open-source API gateways, both built on NGINX and Lua. APISIX differentiates itself with a fully dynamic architecture powered by etcd, higher single-core throughput, and a broader protocol support matrix, while Kong offers a mature enterprise ecosystem with extensive third-party integrations and a large plugin marketplace.
Overview#
Both projects serve as high-performance, extensible API gateways for microservices architectures. Kong was open-sourced in 2015 and has built a substantial commercial ecosystem around Kong Gateway Enterprise, Kong Konnect, and the Kong Plugin Hub. Apache APISIX entered the Apache Software Foundation incubator in 2019 and graduated as a top-level project in 2020, with rapid community growth.
Both projects are recognized as production-grade gateways and see active production deployments worldwide.
Architecture Comparison#
The architectural differences between APISIX and Kong are fundamental and affect day-to-day operations, scalability, and deployment complexity.
Apache APISIX Architecture#
APISIX uses NGINX as its data plane with Lua plugins running in the request lifecycle. Configuration is stored in etcd, a distributed key-value store that pushes changes to all gateway nodes in real time via watch mechanisms. This architecture means that route changes, plugin updates, and upstream modifications take effect within milliseconds without requiring restarts or reloads. There is no relational database dependency.
The etcd-based design gives APISIX a stateless data plane: any node can be added or removed without migration steps or database schema changes. This makes horizontal scaling straightforward and reduces operational overhead significantly in Kubernetes environments where pods are ephemeral.
Kong Architecture#
Kong also uses NGINX and Lua for its data plane. Configuration is stored in PostgreSQL or Cassandra (though Cassandra support has been deprecated in newer versions). Kong's DB-mode requires database migrations when upgrading, and configuration changes propagate through a polling mechanism with a configurable cache TTL, which introduces a delay between API calls to the Admin API and actual enforcement at the proxy layer.
Kong also offers a DB-less mode where configuration is loaded from a declarative YAML file, which eliminates the database dependency but sacrifices the ability to modify configuration dynamically through the Admin API at runtime. Kong's commercial offering, Konnect, provides a managed control plane that addresses many of these operational concerns.
Performance Benchmarks#
Performance characteristics matter at scale, where even small per-request overhead compounds into significant infrastructure costs.
Key architectural differences that affect performance:
- Route matching: APISIX uses a radix tree-based routing algorithm. Kong uses a different matching approach. The routing algorithm affects lookup time as the number of routes grows.
- Configuration propagation: APISIX pushes configuration changes from etcd to all nodes in real time. Kong's DB-mode polls the database on a configurable interval, introducing a delay between configuration changes and enforcement.
- Memory model: Both use NGINX's event-driven architecture, but their plugin execution models differ in per-request allocation patterns.
We recommend benchmarking both gateways with your actual workload, plugin chain, and hardware to get meaningful performance comparisons. Vendor-published benchmarks often test under ideal conditions that may not reflect your production environment.
For many production deployments, both gateways provide sufficient throughput, and the choice often depends on factors beyond raw performance such as ecosystem maturity, plugin availability, and operational familiarity.
Feature Comparison#
| Feature | Apache APISIX | Kong (OSS) |
|---|---|---|
| Plugin count (built-in) | 80+ | 40+ (OSS), 200+ (Enterprise) |
| Protocol support | HTTP/1.1, HTTP/2, HTTP/3, gRPC, WebSocket, TCP/UDP, MQTT, Dubbo | HTTP/1.1, HTTP/2, gRPC, WebSocket, TCP/UDP |
| Dashboard | Apache APISIX Dashboard (OSS) | Kong Manager (Enterprise only) |
| Admin API | Full REST API, fully dynamic | REST API, DB-mode or DB-less |
| Service discovery | Nacos, Consul, Eureka, DNS, Kubernetes | DNS, Consul (others via plugins) |
| Kubernetes ingress | APISIX Ingress Controller (CRD-based) | Kong Ingress Controller (KIC) |
| AI gateway capabilities | ai-proxy plugin, multi-LLM routing | AI Gateway plugins (Enterprise) |
| Multi-language plugin support | Go, Java, Python, Wasm, Lua | Go, JavaScript, Python (PDK) |
| Configuration storage | etcd (distributed, real-time) | PostgreSQL (requires migrations) |
| Canary/traffic splitting | Built-in traffic-split plugin | Canary plugin (Enterprise) |
Both gateways support core functionality like rate limiting, authentication (JWT, OAuth 2.0, API key, LDAP), load balancing, health checks, and circuit breaking. The primary differences lie in the breadth of built-in features available in the open-source edition versus features gated behind enterprise licensing.
Plugin Ecosystem#
APISIX ships with over 80 built-in plugins covering authentication, security, traffic management, observability, and protocol transformation. Notably, plugins for serverless functions (running custom Lua, Java, or Go code inline), AI proxy routing, and advanced traffic management are available in the open-source edition.
Kong's open-source edition includes approximately 40 built-in plugins, with a substantial number of additional plugins available through Kong Plugin Hub and the enterprise edition. Kong's plugin marketplace includes many third-party and partner-contributed plugins, giving it a broader ecosystem for specific vendor integrations like Datadog, PagerDuty, and Moesif.
For custom plugin development, APISIX supports external plugins via gRPC-based plugin runners in Go, Java, and Python, as well as Wasm-based plugins that run in a sandboxed environment. Kong offers a Plugin Development Kit (PDK) supporting Go, JavaScript, and Python alongside native Lua plugins. Both projects accept community-contributed plugins, and their ecosystems continue to grow.
Kubernetes Integration#
Both gateways offer mature Kubernetes ingress controllers, though they differ in design philosophy.
The APISIX Ingress Controller supports both custom resource definitions (CRDs) specific to APISIX and standard Kubernetes Ingress resources. It communicates with the APISIX data plane through the Admin API and supports Gateway API, the emerging Kubernetes standard for traffic management. Configuration changes propagate instantly through etcd.
The Kong Ingress Controller (KIC) also supports CRDs and standard Kubernetes Ingress resources, with Kong-specific annotations for extended functionality. KIC translates Kubernetes resources into Kong configuration, applying them through the Admin API. KIC has a longer track record in production Kubernetes environments and benefits from extensive documentation and community resources.
Both controllers are actively maintained and see regular releases aligned with Kubernetes version updates.
Community and Ecosystem#
| Metric | Apache APISIX | Kong |
|---|---|---|
| License | Apache 2.0 | Apache 2.0 (OSS) |
| Governance | Apache Software Foundation | Kong Inc. |
| First release | 2019 | 2015 |
APISIX benefits from Apache Software Foundation governance, which ensures vendor-neutral development and community-driven roadmap decisions. Kong benefits from the backing of Kong Inc., which provides dedicated engineering resources, enterprise support, and a commercial ecosystem that many large organizations value.
Both projects maintain active community forums, Slack channels, and regular release cadences. Kong's longer market presence gives it an advantage in terms of available tutorials, third-party integrations, and consultant familiarity.
When to Choose Apache APISIX#
APISIX is the stronger choice when your requirements include:
- Dynamic configuration at scale: Environments where routes and plugins change frequently benefit from etcd-based instant propagation without restarts.
- Maximum open-source functionality: Teams that need advanced features like traffic splitting, AI proxy, and multi-protocol support without enterprise licensing.
- High-performance requirements: Workloads where per-request latency and single-core throughput directly impact infrastructure costs.
- Kubernetes-native deployments: Organizations adopting Gateway API and wanting tight integration with cloud-native service discovery (Nacos, Consul, Eureka).
- Vendor-neutral governance: Teams that prefer Apache Software Foundation stewardship over single-vendor control.
When to Choose Kong#
Kong is the stronger choice when your requirements include:
- Mature enterprise ecosystem: Organizations that need commercial support, SLA guarantees, and a proven enterprise deployment track record.
- Extensive third-party integrations: Environments with specific vendor integration needs covered by Kong's plugin marketplace.
- Existing Kong investment: Teams already running Kong in production where migration cost outweighs technical advantages.
- Managed control plane: Organizations that prefer a SaaS-managed control plane (Kong Konnect) to reduce operational burden.
- Broad hiring market: Teams that can more easily find engineers with Kong experience due to its longer market presence.
FAQ#
Can APISIX and Kong run side by side during a migration?#
Yes. Both gateways can operate in parallel by splitting traffic at the load balancer level. A common migration strategy routes new services through APISIX while existing services continue running through Kong. Gradual traffic shifting with health checks ensures zero-downtime migration. The timeline depends on the number of routes, custom plugins, and testing requirements.
Is APISIX harder to operate because it requires etcd?#
etcd adds a dependency compared to Kong's DB-less mode, but in practice, etcd is a well-understood, battle-tested component already present in most Kubernetes clusters (it is the backing store for Kubernetes itself). Operating etcd requires standard distributed systems practices: run an odd number of nodes (3 or 5), monitor disk latency, and maintain regular snapshots. For teams already running Kubernetes, etcd operational knowledge is typically already available. The operational cost of etcd is generally lower than managing PostgreSQL migrations required by Kong's DB-mode.
Which gateway has better AI and LLM support?#
Both gateways are investing in AI gateway capabilities, but they approach it differently. APISIX provides the ai-proxy plugin in its open-source edition, supporting multi-model routing, token-based rate limiting, and prompt transformation for major LLM providers. Kong offers AI Gateway plugins primarily through its enterprise edition and Konnect platform. For teams building AI-powered applications on an open-source budget, APISIX currently provides more built-in AI functionality without licensing costs.
How do the two gateways compare on gRPC and streaming support?#
APISIX provides native gRPC proxying, gRPC-Web transcoding, and HTTP-to-gRPC transformation out of the box, along with support for HTTP/3 (QUIC), Dubbo, and MQTT protocols. Kong supports gRPC proxying and gRPC-Web through plugins, with HTTP/2 support on both client and upstream connections. For teams heavily invested in gRPC or multi-protocol architectures, APISIX's broader built-in protocol support reduces the need for custom plugins or sidecars.