Apache APISIX vs Kong:
93x Faster & 200% QPS

The most fundamental difference between Apache APISIX and Kong is their configuration storage backend. This single architectural choice affects performance, operational complexity, and how your gateway behaves in production.

Apache APISIX: etcd-Powered Architecture

Apache APISIX uses etcd as its configuration store. etcd is a distributed key-value store (the same technology Kubernetes uses) that provides real-time watch capabilities. When you update a route, plugin, or upstream configuration, APISIX data planes receive the change within milliseconds via etcd's watch mechanism — no polling, no cache invalidation, no restarts.

This architecture enables a clean control plane / data plane separation. The data plane (APISIX) has no direct database dependency at runtime. If etcd goes down temporarily, APISIX continues routing traffic using its in-memory configuration. This makes APISIX extremely resilient and easy to scale horizontally — just add more data plane nodes.

Kong: PostgreSQL / DB-less Architecture

Kong traditionally relies on PostgreSQL (or Cassandra, now deprecated) as its configuration store. Configuration changes are written to the database, then propagated to Kong nodes via a polling-based cache invalidation mechanism. The default polling interval is 5 seconds, meaning configuration changes can take several seconds to propagate across your cluster.

Kong also offers a DB-less mode that loads configuration from a declarative YAML file, eliminating the database dependency. However, DB-less mode does not support the Admin API for runtime configuration changes — you must regenerate and reload the YAML file, which is less flexible for dynamic environments.

Independent benchmarks consistently show that Apache APISIX outperforms Kong in throughput, latency, and resource efficiency. Here are the key numbers from our APISIX 3.0 vs Kong 3.0 benchmark conducted on identical hardware:

Why APISIX Is Faster

Both APISIX and Kong are built on NGINX and OpenResty, so what explains the performance gap? The main factors are:

• No database queries in the hot path. APISIX routes requests entirely from in-memory data structures synchronized via etcd watches. Kong's traditional mode involves database lookups and cache validation on the request path.
• Optimized routing engine. APISIX uses a radix tree for route matching, which provides O(k) lookup time (where k is the URL path length). Kong uses a different matching algorithm that can be slower with large numbers of routes.
• Leaner plugin execution. APISIX's plugin runner is optimized for minimal overhead per request. The 93x difference in maximum latency is largely attributable to Kong's occasional garbage collection pauses and database cache misses.

These differences become more pronounced at scale. In production deployments handling millions of requests per second, the 2x QPS advantage translates directly to 50% fewer servers needed for the same workload — a significant cost saving on infrastructure.