Yilialinn commented on code in PR #2121:
URL: https://github.com/apache/apisix-website/pull/2121#discussion_r4032985376
##########
website/learning-center/apisix-vs-kong.md:
##########
@@ -1,144 +1,156 @@
---
-title: "Apache APISIX vs Kong: Feature Comparison & Performance Benchmarks"
-description: "Compare Apache APISIX and Kong API Gateway across architecture,
performance, plugin ecosystem, Kubernetes support, and migration tradeoffs."
+title: "Apache APISIX vs Kong: Architecture, Features, and Tradeoffs"
+description: "Compare Apache APISIX and Kong across deployment topology,
configuration, plugins, Kubernetes integration, performance testing, and
migration tradeoffs."
slug: apisix-vs-kong
date: 2026-04-14
tags: [comparison, apisix, kong, api-gateway]
hide_table_of_contents: false
faq:
- - q: "Can APISIX and Kong run side by side during a migration?"
+ - q: "Does Apache APISIX always require etcd?"
a: >-
- 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.
- - q: "Is APISIX harder to operate because it requires etcd?"
+ No. APISIX uses etcd in its traditional and decoupled deployment modes,
but its standalone modes use a complete local configuration file or full-state
API updates instead. Teams should compare the automation, recovery, and
state-management tradeoffs of the specific mode they plan to operate.
+ - q: "Can Kong configuration be imported directly into Apache APISIX?"
a: >-
- 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.
- - q: "How do the two gateways compare on gRPC and streaming support?"
+ There is no universal direct conversion because the gateways use
different entity schemas, route matching rules, plugin phases, credentials, and
state models. A migration should map and test each service, route, consumer,
plugin, certificate, and operational behavior before traffic is shifted.
+ - q: "Which gateway is a better fit for Kubernetes?"
a: >-
- 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.
+ Both projects provide Kubernetes ingress controllers, so the decision
depends on the exact Ingress, Gateway API, and custom resources your platform
requires. Test the relevant support matrix, status reporting, secret handling,
upgrade behavior, and configuration convergence for the controller version you
intend to deploy.
---
-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.
+Apache APISIX and Kong are open-source API gateways with mature routing,
traffic management, authentication, observability, and Kubernetes integrations.
Their most important differences are not a single feature count or benchmark
result, but how they store and distribute configuration, which deployment
models they support, and how their plugin ecosystems are packaged.
-## Overview
+Apache APISIX combines an Apache-governed project and [100+ open-source
plugins](/plugins/) with etcd-backed and standalone deployment modes. Kong
offers database-backed, DB-less, and hybrid control-plane/data-plane
topologies, plus an ecosystem that includes open-source, Enterprise-only, and
separately licensed plugins. The right choice depends on the topology,
policies, extensions, and operating model your team needs.
-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.
+For a broader shortlist, see the [open-source API gateway
comparison](/learning-center/open-source-api-gateway-comparison/).
-Both projects are recognized as production-grade gateways and see active
production deployments worldwide.
+## APISIX vs Kong at a Glance
-## Architecture Comparison
+| Dimension | Apache APISIX | Kong Gateway |
+|---|---|---|
+| Project and product model | Apache Software Foundation open-source project |
Open-source gateway with vendor-backed commercial products and services |
+| Deployment topology | Traditional, decoupled control/data plane, and
standalone modes | Traditional database-backed, DB-less, and hybrid
control/data plane modes |
+| Configuration state | etcd in traditional and decoupled modes; local
YAML/JSON or full-state API updates in standalone mode | Database in
traditional mode; declarative configuration held by each node in DB-less mode;
control plane distributes configuration to data planes in hybrid mode |
+| Runtime configuration | Admin API with etcd-backed updates; standalone
behavior depends on file-driven or API-driven mode | Admin API in
database-backed deployments; full declarative reloads in DB-less mode;
control-plane updates in hybrid mode |
+| Plugin ecosystem | 100+ open-source plugins, native Lua plugins, external
plugin runners, and experimental Wasm support | Plugin Hub with open-source,
Enterprise-only, and license-required plugins; custom plugins through supported
PDKs |
+| Kubernetes | APISIX Ingress Controller supports Kubernetes Ingress,
supported Gateway API resources, and APISIX custom resources | Kong Ingress
Controller translates Ingress, Gateway API, and Kong custom resources into Kong
Gateway configuration |
+| Performance evaluation | Official APISIX benchmarks are available, but must
be interpreted using their documented environment and workload | Official Kong
benchmarks are available, with results that depend on version, topology,
plugins, and test environment |
-The architectural differences between APISIX and Kong are fundamental and
affect day-to-day operations, scalability, and deployment complexity.
+Feature availability changes across versions and Kong editions. Verify any
requirement against the current documentation for the exact version and
distribution you plan to deploy.
-### Apache APISIX Architecture
+## Architecture and Configuration
-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.
+### Apache APISIX
-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.
+Apache APISIX is built on NGINX and LuaJIT. In its traditional mode, a node
handles both control-plane and data-plane responsibilities, while decoupled
mode separates those roles. Both modes can use etcd as the configuration
provider. APISIX nodes watch configuration changes in etcd and update in-memory
routing and plugin state without replacing worker processes.
-### Kong Architecture
+APISIX also provides [standalone deployment
modes](/docs/apisix/deployment-modes/) that do not use etcd as the
configuration center. File-driven standalone mode loads a complete YAML or JSON
configuration, while API-driven standalone mode accepts full-state updates
through its dedicated configuration API. These modes have different automation
and state-management tradeoffs from the default etcd-backed model.
Review Comment:
Fixed in 5c6445c. File-driven standalone is now presented throughout the
FAQ, comparison table, architecture, operational tradeoffs, propagation, and
selection guidance as the general etcd-free path. API-driven standalone is
scoped to APISIX Ingress Controller and ADC integrations that replace full
in-memory routing state through the dedicated API.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
