Regarding third-party clients: #25772 (reply in thread)

Good question! First of all, this is a big transition, and it's not going to happen at once: we are committed to maintain stability and full functionality of the ORM, and the changes will be gradual. We will have a WebAssembly Rust component at the time being, however it will not interact with the database.

As for the performance, the biggest bottleneck right now is the serialization of data and passing it through the FFI boundary. This will go away, and the preliminary benchmarks on the prototype show massive performance improvements. More than that, the new architecture allows to prepare Prisma queries and re-use the prepared queries with virtually no runtime cost compared to using a raw SQL query.

We will share more details with the community soon, so stay tuned!

@aqrln - Awesome, thanks for the detail!

I'm not too familiar with the code; does the generate command use Rust or TS currently?

Both. It already doesn't use any natively compiled engines though, only the @prisma/prisma-schema-wasm package. When writing a custom generator, you might not even be aware that any Rust code is used for schema parsing and generating the DMMF, it's pretty well encapsulated.

That WASM module is fairly general purpose though and powers other things as well (like the language server and the VS Code extension). The generate command itself and the Prisma Client generator are all pure TypeScript.

wondering about this as well

That's an excellent question and we're hearing it a lot! We hope to continue to enable third-party language clients but the precise path forward isn't clear yet. Here's what we're thinking:

• We'd like to talk to third-party client maintainers to understand what parts of the existing Prisma architecture they depend on specifically
• In the next three months we'll release an early access preview of our new TS-based architecture to help guide the discussion on supporting them
• If possible, we'll extract the Rust elements they depend on into a separate package maintained externally
• We want to make the code generation process extensible and adaptable to support generating assets besides the Prisma TS client

That's an excellent question and we're hearing it a lot! We hope to continue to enable third-party language clients but the precise path forward isn't clear yet. Here's what we're thinking:

• We'd like to talk to third-party client maintainers to understand what parts of the existing Prisma architecture they depend on specifically
• In the next three months we'll release an early access preview of our new TS-based architecture to help guide the discussion on supporting them
• If possible, we'll extract the Rust elements they depend on into a separate package maintained externally
• We want to make the code generation process extensible and adaptable to support generating assets besides the Prisma TS client

To be honest, if the subsequent Prisma engine still builds WASM modules, I hope to provide CAPI versions simultaneously. Building WASM modules means it is easy to create CAPI copies.

The reason why I want to have a CAPI version so much is that it can provide engine support for any third-party language.

At present, I have paused the work on Prisma Dart and waited for Prisma v7. Starting from Prisma 6.2, Prisma can no longer support running on Flutter (capi engine is broken). But if I continue to use the binary version, it is not in line with the Prisma manifesto. So I paused.

The pull request is not meaningless and can still be merged. There's a very long way to the full TypeScript core, and the code this PR changes is still going to be used in 2025, albeit in a different manner, with better architecture and without native binaries.

Hi @kibertoad, you’re correct that CockroachDB won’t be a primary focus for us going forward, but we want to reassure you that support for CockroachDB isn’t going away. We’ll continue to prevent regressions, though some issues or new functionality may require community contributions since it’s not our primary focus.

That said, we’re actively working on making Prisma’s codebase more modular, which should make it easier for the community to contribute and extend support for databases like CockroachDB. For partners with an enterprise support contract, we can also allocate engineering resources to address specific issues.

thank you, this is good news!

As you can derive from this very long issue. A lot of ppl offered their time and expertise to get it done, I assume that they cannot do it without getting their hands on crates from prisma. I further assume that those are not open source. So the resource argument is a strawman because other ppl would have done the job. Alignment to the goals comes also back to profitability or widespread support is not a team/company goal.
I don't like to be gaslit on a subject that started in 2020 and was neglected ever since.
I see it more straightforward, it can be done, a lot of ppl already offered to have it done, the only showstopper is prisma in this matter to enable them to make it happen. Prisma explicitly decided against it.
There was a reaction from a contributor after more like 1 year then after 3 years another and finally got shot down in last december.
The original oracle connector issue is even older prisma/prisma1#1644 2018
#15714 also got this from a maintainer who tried the same gaslighting on me.
I really not appreciated such kind of behavior.

A lot of ppl offered their time and expertise to get it done, I assume that they cannot do it without getting their hands on crates from prisma. I further assume that those are not open source. So the resource argument is a strawman because other ppl would have done the job.

This is incorrect. The entire Prisma codebase is open source. If someone wanted to build an Oracle connector, they could do so and open a PR. There are already several examples of community-built driver adapters, which you can find here: https://www.prisma.io/docs/orm/overview/databases/database-drivers#community-maintained-database-driver-adapters.

Alignment to the goals comes also back to profitability or widespread support is not a team/company goal.

You continue to assume this when I have clarified that profitability is not the case. The ORM is open source. We have an entirely separate team working on the ORM vs one that works on on commercial products.

The original oracle connector issue is even older prisma/prisma1#1644 2018

That issue is from Prisma 1, which is not even the same package that we are talking about now, or the Prisma ORM as we currently know it.

Since then, we’ve introduced DriverAdapters, a feature that allows anyone to extend the ORM independently. Before this release, extending the ORM required significant collaboration with our team. With DriverAdapters, that dependency has been eliminated. We still carry the burden to merge PRs, but that is entirely doable should someone send a PR our way. We merge relevant PRs all the time.

I don't like to be gaslit on a subject that started in 2020 and was neglected ever since.

"Neglect" is not the appropriate term. If this topic were neglected, we wouldn’t respond every time it is raised. Why do we engage? Because we are committed to addressing misconceptions. The manifesto, linked above, clearly outlines the databases that are our priority. These priorities are informed by research, community feedback/wants/asks, industry trends, and our strategic goals.

Our decisions come down to resource allocation and prioritization. While you might see this as a single unresolved issue, we view it in the context of all community needs. Allocating resources to something as complex as Oracle support could prevent us from addressing other, higher-priority community requests. We aim to avoid frustration from multiple angles by taking a more balanced approach.

I see it more straightforward, it can be done, a lot of ppl already offered to have it done, the only showstopper is prisma in this matter to enable them to make it happen. Prisma explicitly decided against it.

It is never as straightforward as it seems. Supporting Oracle is a challenging and resource-heavy endeavor. Could we use community help, of course. But our code base is also not that easy to grok, and we recognize that. We are taking steps to address that as well. The recent announcement of decoupling of the Rust engine will certainly help with that.

#15714 also got this from a maintainer who tried the same gaslighting on me. I really not appreciated such kind of behavior.

The response you received was a direct reflection of our thinking at that time. Just like I am now outlining our thinking at the present moment. Communication is always subject to interpretation, but I can assure you that the Prisma team values constructive feedback and community collaboration. While our team strives to serve as many community members as possible, it is impossible to meet every request. That is an unfortunate reality, but we remain committed to transparency and respectful dialogue.

As I have mentioned in the comment above, give me a few days on this and I will circle back.

Here it goes again. Driver Adapters are not the same as providers or connectors as far as I understand it. Hence it is not possible to just write an oracle adapter if you don't have a fitting provider written in Rust. If that is open source too, that would be great.
Yes, the issue is from prisma 1to underline that this issue exists since 2018.

Driver Adapters are not the same as providers or connectors as far as I understand it

That understanding is incorrect. DriverAdapters serve as a foundational step toward writing exactly that: database driver adapters.

Hence it is not possible to just write an oracle adapter if you don't have a fitting provider written in Rust

This highlights why this area is a moving target—our efforts are focused on removing the dependency on the Rust engine altogether and to make it even more easier for the community to contribute, all the while improving performance and reliability.

If that is open source too, that would be great.

It is, as are all the other database drivers. If someone really wanted to take on writing an Oracle driver, the source material for everything is available to them:

• https://github.com/prisma/prisma-engines
• https://github.com/orgs/prisma/repositories?q=rust

Yes, the issue is from prisma 1to underline that this issue exists since 2018.

That point is not directly relevant to the current discussion. Software evolves, and so should the framing of the discussion. Referencing the age of an issue does not inherently strengthen your argument, especially if the underlying architecture has changed significantly since then.

Here it goes again.

I’d like to offer some constructive feedback. Comments like this can come across as passive-aggressive. I am engaged in a professional dialogue and have already communicated that I intend to discuss this matter with the team. I would appreciate it if you could refrain from such remarks. They risk undermining the professionalism of this exchange and may inadvertently reflect the same behavior you have criticized—revisiting a topic in a manner that could be perceived as gaslighting.

Following up on this...One of the key challenges in enabling external contributions for building an Oracle adapter has been the inherent complexity of our codebase. We recognize that this complexity has posed barriers, and our recent announcement regarding the removal of the Rust component(s) is aimed at reducing this challenge.

Dedicating resources to building something that we know will need to fundamentally change is not ideal. Therefore, for the near term our focus will be on delivering the necessary capabilities that pave the way towards delivering a code base that is easier and faster to work and create with.

Once that is out there, we'll revisit all requested enhancements, including an Oracle driver, and build out a roadmap.

Hey @tonypapousek, this is definitely an issue we want to resolve in 2025 👍🏻

Hey @tonypapousek, this is definitely an issue we want to resolve in 2025 👍🏻

That's excellent news, thanks!

yeah pretty much, unfortunately.

I am also ready to give up prisma-dart; because this move makes it impossible for me to continue to maintain prisma-dart.

It even forced me to switch the server built in Dart to Bun/Node for development. It is very heavy for me because it is difficult to find an alternative in Dart (there is not even a stable database connector under Dart)

Thanks for sharing your feedback.