DB-less mode

Using the DB-less and declarative configuration mode is one of the quickest and easiest ways to get started with Kong Gateway. For this mode, start with a Kong.yml file (which includes declarative configuration for Kong objects like services, plugins, and routes).

We can start Kong by providing this declarative configuration. One note here is that the Kong Admin API will only be available in Read Only mode. But if you want to make any changes to the configuration, you’ll need to submit the file to the /config endpoint with the new configuration.

Because this configuration doesn’t rely on pulling data from anywhere or automatic updates, we call this DB-less mode. It’s extremely simple and lightweight. If you’re running the Kong Ingress Controller, this is a great option because KIC deploys and ships the declarative configuration through this config API.

Traditional mode

If you’re looking to scale your deployment and make incremental changes to your configuration, you’ll need to use the Kong Admin API.

This requires introducing a database. The Kong Admin API will be available with configurations for services, plugins, and routes. We call this traditional mode.

This can be used with just a single cluster node or with multiple clusters — but all of them will derive their configuration from the database and the configuration established there. You’ll still need a load balancer in front of the database to assist with routing (this can also be Kong), but the configuration will be consistent.

With this deployment mode, you can also use Kong Manager and the Developer Portal with the database. But one caution here: you may run into a challenge where you’re spending a lot of effort maintaining the database, instead of on your applications. In order to optimize performance, Kong supports a cluster of Postgres, integration with read-only replicas, and doesn’t call from the database each time.

Hybrid mode

If you’re still looking to solve the challenge of having too many calls from the database, you can deploy Kong in hybrid mode.

With this mode, different Kong nodes take on different Kong roles. This is done by creating a Kong instance that is explicitly serving the role of data plane (there can be multiples) with another instance that manages centralized configuration called the control plane. The data plane (or data planes) serves user traffic and is separated from the control plane.

In this mode, only the control plane talks to the database, and it isn’t directly serving user traffic.

Kong Manager and Developer Portal are available in this mode as well and are part of the control plane, working directly with the database. So this deployment mode solves a lot of the scaling challenges you might face in traditional mode.

Kong Konnect

For organizations with many APIs looking to segregate deployment based on environment (for example, different environments for development, QA, regions, etc), the best deployment option is Kong Konnect.

In this deployment mode, we still have our Kong data planes, but the control plane is a cloud-managed control plane. This allows you to segregate and separate different environments using Runtime Manager. Kong Konnect also includes a Service Hub, where you can discover and publish your services — along with Developer Portal as a managed solution.

Kong Konnect also has built-in analytics for observing and monitoring your Kong instances. This allows you to have different Runtime Groups running in different environments (Docker, Kubernetes clusters, VMs, etc). With the managed cloud control plane in Kong Konnect, configuration is centralized and available to submit into different environments. This allows you to support GitOps or APIOps configurations. And with a SaaS control plane, the Kong Konnect team is able to quickly and frequently release new features, updates, and changes.