Kong can run with a database to store coordinated data between Kong nodes in
a cluster, or without a database, where each node stores its information
independently in memory.
When using a database, Kong will store data for all its entities (such as
routes, services, consumers, and plugins) in PostgreSQL,
and all Kong nodes belonging to the same cluster must connect to the same database.
Kong supports PostgreSQL versions 9.5 and above.
When not using a database, Kong is said to be in “DB-less mode”: it will keep
its entities in memory, and each node needs to have this data entered via a
declarative configuration file, which can be specified through the
declarative_config
property, or via the Admin API using the /config
endpoint.
When using Postgres as the backend storage, you can optionally enable Kong
to serve read queries from a separate database instance.
When the number of proxies is large, this can greatly reduce the load
on the main Postgres instance and achieve better scalability. It may also
reduce the latency jitter if the Kong proxy node’s latency to the main
Postgres instance is high.
The read-only Postgres instance only serves read queries, and write
queries still go to the main connection. The read-only Postgres instance
can be eventually consistent while replicating changes from the main
instance.
At least the pg_ro_host
config is needed to enable this feature.
By default, all other database config for the read-only connection is
inherited from the corresponding main connection config described above but
may be optionally overwritten explicitly using the pg_ro_*
config below.