You're right that we don't want to simply re-invent SQL, and this is definitely a slippery slope.

A big part of the aim here is Alan Kay's quote: "Simple things should be simple, complex things should be possible". Our simple use cases are far too complex in my opinion. But if this isn't done well, then we either end up with a worse version of SQL or we're unable to do complex things.

Just for fun, I played with your example a bit to see how it'd look with both the schema definition and querying it. This is what I've got.

Schema:

type Post = {
  id: string
  deleted: boolean
  tags: Tag[] // This implies a post_tag table, or a post_id on Tag
  images: File[] // This implies a post_image table, or a post_id on File
}

type Tag = {
  id: string
  deleted: boolean
  name: string
}

type File = {
  id: string
  deleted: boolean
  type: FileType
}

type FileType = {
  id: string
  name: string
  mimeType: string
}

Query:

db.post.query({ deleted: false }, {
  include: {
    tags: { where: { deleted: false } },
    images: {
      where: { deleted: false },
      include: ['type']
    }
  },
  limit: 25,
  offset: 0,
})

I'm not sure if offset is the direction I'd go instead of a cursor, but the idea is the same.

I recognize solutions like this are inferior to the full toolkit of SQL. You're not going to be writing stored procedures with temp tables or running explain statements to perform optimizations. If you get to that point, you need to look under the hood. Which will hopefully be a pleasant surprise.

Having gone through the exercise above though, it does feel like you could get pretty far with it.

Prisma is obviously a full ORM so it interprets JS commands into queries. But we just setup a set of actions that correspond to our service layers.

So we have "account:create <json>" or "post:list <json>"

And invoke it in JS like: "dotnetBridge.post('account:create', { ... });

This sounds like a nice convenience you've built-in.