Support for database abstraction.

[RussellLuo]

Kong is awesome in many aspects, but I can not use it in my work now.

The major problem is that Kong only supports Cassandra, which is not used in our company (we use MongoDB). And it is a hard work to add a new database dependency.

There have been some related issues #183, #331. But I open this issue not to request a new specific database support, but to suggest a database abstraction (or database extension) support. With the abstraction support, we can easily write extensions to adapt different databases into Kong.

Kong already has many wonderful features and plugins, but currently the feature I need most is database abstraction. While it is hard to accomplish it at once, it is always important (and also easy) to plan ahead. Since the more features and plugins the Kong team develops, the more hard the database abstraction becomes.

[ahmadnassri]

thanks @RussellLuo that's actually the plan and the next item on our list to get to #183 & #331

will keep this issue open for tracking progress.

[thibaultcha]

Well, technically database abstraction has always been on our mind and is almost already supported. Kong used to support both SQLite and Cassandra in its early days. The current design is already a pluggable DAO system and you can already write your own DAO for a given database.

I say "almost" already supported because as of now, it would require some small updates to make the tests run for any DAO (as of now they are more specific to Cassandra), and eventually minor adjustments in Kong itself, but that would be all.

[RussellLuo]

Thanks for your reply, @ahmadnassri and @thibaultcha.

Sorry for not mentioning DAO. The existing DAO system is already the database abstraction in Kong, but it needs more improvement to make the work of database customizing easier.

Therefore, strictly speaking, what I really want is a more generic DAO system. While all of Kong itself, plugins and tests use the exact same db interface provided by the generic DAO system, eventually Kong will become database agnostic.

[AndrewDryga]

+1 for MongoDB

[thibaultcha]

Consider it resolved with the addition of PostgreSQL and the new DAO.

[oreza]

Sorry for any confusion, does Kong support Mongo?

[sonicaghi]

@oreza only Cassandra and Postgres (Redis for the rate limiting). No plans to add anything else medium term.

[jaesga]

Any plans yet to have support for MongoDB? Or only Cassandra and PostgreSQL for the moment?

[jstoja]

To answer to @thibaultcha #883 (comment)
I think MongoDB and PostgreSQL resolve two different use cases, Mongo is:

• Way easier to have HA/Replication/... with it than with PostgreSQL
• Way lighter and easier to manage than Cassandra

I totally understand that it's not in your roadmap and the addition has limited interest for the company, but you'd probably accept contributions on this one, if so, could you describe a bit the constraints you might see with it, and the conditions of acceptation ?

[jstoja]

I allow myself to add @sonicaghi in the loop to maybe re-open this and avoid creating a new issue for the same request.

[thibaultcha]

@jstoja We do not have plans to support MongoDB in the short or long term. I doubt we would accept a contribution for it, as supporting different datastores already is an enormous burden on our shoulders maintenance-wise, let alone a datastore we have no plans of supporting. On top of that, our requirements are better fitted with an SQL database - Cassandra already is painful enough to maintain.

[thibaultcha]

By the way, this is a close issue. Better not hijack a closed thread. A better solution would be to post on our new community forum: http://discuss.konghq.com/

Thanks!