You are browsing documentation for an outdated version. See the latest documentation here.

Accessing the Datastore

Kong interacts with the model layer through classes we refer to as “DAOs”. This chapter will detail the available API to interact with the datastore.

Kong supports two primary datastores: PostgreSQL and Cassandra .

We don’t recommend using Cassandra with Kong Gateway, because support for Cassandra is deprecated and planned to be removed.

kong.db

All entities in Kong are represented by:

• A schema that describes which table the entity relates to in the datastore, constraints on its fields such as foreign keys, non-null constraints etc. This schema is a table described in the plugin configuration chapter.
• An instance of the DAO class mapping to the database currently in use. This class’ methods consume the schema and expose methods to insert, update, select and delete entities of that type.

The core entities in Kong are: Services, Routes, Consumers and Plugins. All of them are accessible as Data Access Objects (DAOs), through the kong.db global singleton:

-- Core DAOs
local services  = kong.db.services
local routes    = kong.db.routes
local consumers = kong.db.consumers
local plugins   = kong.db.plugins

Both core entities from Kong and custom entities from plugins are available through kong.db.*.

The DAO Lua API

The DAO class is responsible for the operations executed on a given table in the datastore, generally mapping to an entity in Kong. All the underlying supported databases comply to the same interface, thus making the DAO compatible with all of them.

For example, inserting a Service and a Plugin is as easy as:

local inserted_service, err = kong.db.services:insert({
  name = "mockbin",
  url  = "http://mockbin.org",
})

local inserted_plugin, err = kong.db.plugins:insert({
  name    = "key-auth",
  service = inserted_service,
})

For a real-life example of the DAO being used in a plugin, see the Key-Auth plugin source code.