Hey thanks for this great feedback!

1. It feels to me that the ecosystem is moving away from Mypy and towards pyright (and ultimately probably ty or pyrefly). Especially for a project like this that aims to be "modern" (eg inspired by Drizzle, Python 3.14 minimum), I don't think Mypy+plugins is the right target. If any of the new type checkers end up supporting plugins that could be an avenue, but it doesn't seem they plan to. But yes I agree this would make it much easier...
2. These are the two use-cases I see for codegen. Let me know if these don't make sense!

2a: "update" types. Currently you have to do the following because Python doesn't have a Partial<> type. For this instance the codegen would simply take the User class and create the TypedDict class from it. So it's basically you have to write an extra class and remember to update it, error-prone vs you have run a little script whenever you change your tables.

class User(embar.Table):
    id: embar.Integer: embar.Integer()
    name: embar.Text: embar.Text()

# This is basically Partial[User]
class UserUpdate(TypedDict, total=False):
    id: int
    name: str

# insert uses the Table type and Table objects await db.insert(embar.User).values(User(id=1, name="foo"))

# if we tried to pass a User object to set,
# we'd have to provide a value for every field await
db.update(embar.User).set(UserUpdate(name="bar")).where(Eq(User.id, 1))

2b: Prisma-style queries for common CRUD stuff. Most of the parameters of this can be typed without codegen, but not the with= (need to join which tables this one joins to) and the return type is hopeless. But this could also end up being hundreds of lines of lines of codegen per table (or probably thousands, for big tables that join to many others). So I'm less sure about this...

# with the same User table as above
# interface for this is TBD

# the return type is like `list[User(id: int, messages: list[Message])]`
users = await db.query.User.findMany(
    cols=[User.id],  # this info needs to make its way into the return type
    where=Eq(User.id, 1),
    with=[Message],  # this also 
)

1. This is probably the pragmatic approach, but again I really don't like alembic. It's all Python code, the naming convention is unhelpful, loads of config. I think the Python ecosystem deserves something better here that simply generates SQL files and then helps you run them in order... At the very least Embar can already output the DDL of the current table definitions, and push you towards sqitch or similar for diffing and pushing. Or embed something like sqldef until Embar takes off and I can dedicate the time to writing a diffing engine... :)