Would Prisma be open to a contribution adding KingbaseES support?

[lifeng5210]

Question

Hello maintainers,

I’m interested in working on support for KingbaseES in Prisma over the next couple of months, and I wanted to ask first whether this kind of contribution would be acceptable to the community and maintainers.

Based on my initial research, KingbaseES has a certain level of compatibility with parts of the PostgreSQL/MySQL ecosystem, which makes me think this adaptation may be technically possible.

To keep the contribution safe and maintainable, my goal would be to:

• keep the design as non-intrusive as possible
• avoid breaking or affecting existing supported databases
• add targeted integration tests for compatibility-related behavior
• follow Prisma’s contribution guidelines and update documentation if needed

I have already started some preliminary validation, and if this direction is considered acceptable, I’d be happy to continue and work toward a Pull Request in the coming months.

Would Prisma maintainers be open to this kind of database adaptation for KingbaseES? If there are any architectural expectations or constraints I should be aware of before starting, I’d really appreciate your guidance.

Thank you.

How to reproduce (optional)

Expected behavior (optional)

No response

Information about Prisma Schema, Client Queries and Environment (optional)

// Add your schema.prisma

// Add any relevant Prisma Client queries here

• OS:

• Database:

• Node.js version:

• Run prisma -v to see your Prisma version and paste it

[cookesan]

This is the kind of change I would get explicit maintainer direction on before starting a large PR.

The supported-databases docs list PostgreSQL, MySQL, MariaDB, SQL Server, SQLite, MongoDB, CockroachDB, and specific managed variants. KingbaseES is not listed there. Even if KingbaseES is compatible with parts of the PostgreSQL/MySQL ecosystem, adding it to Prisma is more than a client-side adapter change: it can touch introspection, migrations, connector behavior, type mapping, native tests, documentation, and long-term support expectations.

If you want to make the proposal easy to evaluate, I would open with a short design issue/PR that answers:

which existing connector it would build on
which SQL dialect differences matter
which Prisma features would be supported or excluded
how CI/integration tests would run
who can maintain the compatibility surface after merge

That gives maintainers a concrete support-cost question instead of only a technical feasibility question.

[nurul3101]

I don't see any feature requests asking for KingbaseES support. The features are prioritised based on demand as well as our internal roadmap. At the moment I am not sure adding support for KingbaseES would be worth it as there is no demand.

[github-actions[bot]]

Hi,

As we have not heard back from you, we are closing this discussion to keep our discussions organized.

Feel free to start a new discussion if this remains relevant.

Thank you for being part of the community!