Yilialinn commented on code in PR #2121: URL: https://github.com/apache/apisix-website/pull/2121#discussion_r4013286117
########## website/learning-center/apisix-vs-kong.md: ########## @@ -1,144 +1,146 @@ --- -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." Review Comment: Fixed in 87b16db. I added three comparison-specific FAQs covering APISIX deployment modes, Kong-to-APISIX migration, and Kubernetes evaluation. The preview build now emits one FAQPage JSON-LD block containing all three questions, while avoiding the inaccurate and generic FAQ copy removed by the refresh. ########## website/learning-center/apisix-vs-kong.md: ########## @@ -1,144 +1,146 @@ --- -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?" - 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?" - 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?" - 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. --- -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. -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. +The current APISIX distribution includes an [embedded Dashboard](/docs/apisix/dashboard/) for managing routes, plugins, and upstreams through the Admin API. Production deployments still need to restrict access to the Admin API and protect its credentials. Review Comment: Fixed in 87b16db. The article now says APISIX supports an embedded Dashboard UI and explicitly qualifies availability by whether the selected package or build includes the compiled UI assets. This matches the current Dashboard documentation and avoids implying that every source checkout or package contains the UI. -- 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]
