Some of the ideas we've built into Prisma are certainly inspired by tools in other languages and we've looked a lot at LINQ and the C# ecosystem in general as we designed Prisma!

However, I believe that one thing that sets Prisma apart is the architecture with a _query engine_ [1] (implemented in Rust) that takes care of query planning and execution on top of which we can add lightweight, language-specific layers to bring Prisma Client to more programming languages. But you're definitely right that a generated database client is not a novel idea per se!

For example, we're already working on Prisma Client for Golang which is already available in alpha!

[1] https://www.prisma.io/docs/reference/tools-and-interfaces/pr...

[2] https://github.com/prisma/prisma-client-go

What exactly does your "query engine"/planner actually do? I understand the role that, for example, the Postgres query planner does.

Is the idea that Prisma might be backing on to multiple databases and therefore needs another planning layer? If so, wouldn't this need to be very specific to the database and schema – knowing that particular fields in one database refer to entities in another? Does Prisma tackle this? How?

Assuming something in the same vein as fizx with the addition that it's probably very similar to what Join Monster tries to solve: https://github.com/join-monster/join-monster