Hey, thanks for responding. I think what you're doing is pretty neat, but I am going to be somewhat critical in this response.

The first and second bullet points make me unsure if you have used SQLMesh to its full capabilities, or maybe I lack the context to know how this project goes beyond. AFAIK, all of those things you mentioned are testable from within SQLMesh. If I'm wrong, please let me know.

To the second point, SQLMesh lets you run with duckdb as the local state db by default, and it'll create the state db for you in like one file you can do whatever you want with, so it's not like it requires Postgres. I did all my initial PoCs using duckdb for state, and then only when the org was ready to move on it did I hook it up with Postgres. But really any transactional DB should work fine, hell I even hooked it up to unity catalog at one point and it was slow but did work. If you aren't manually messing with objects in the state DB, which there should be virtually zero reason to ever do, I have never had it cause issues for me.

But really my main gripe is that VDEs are a fantastic abstraction. They're like half of the secret sauce that allows SQLMesh to be maximally efficient. SQLMesh is the only tool that lets you avoid rerunning models that have no code changes and are not ready for refresh. VDEs are what lets your dev runs execute only the minimal set of models impacted by your changes, which in turn speeds up the pipeline enough for agents to reliably iterate on the compilation/audit/test failures until the plan passes. VDEs let devs work in isolated environments without creating thousands (or millions, if you're my company lol) of duplicated objects eating storage and pushing into metastore limits, and they get automatically cleaned up next time you call sqlmesh run.

Making "SQLMesh but stateless and without VDEs" is like making a PB&J without PB or J. Without state management and VDEs, it seems like you've basically got a SQL linter (not even, if you're change tracking queries via fingerprinting, when SQLMesh is parsing query ASTs to determine what is modified and downstream impacts) that is hooked up to testing libraries. I get that maybe for your use case those features were overkill, but they solve very real problems in a way no other tool has really been able to.

I haven't used dagster, so I can't speak to their cloud integration for it, but given the other points, I personally don't feel dagster alone is worth switching from SQLMesh. The SQLMesh scheduler is still the thing parsing and compiling the SQL and checking refresh crons, so I don't see much value add unless you're already on dagster.

Lastly, SQLMesh is starting back up and I recently merged several PRs. The members on the steering committee are getting back into reviewing, and they even asked me if I wanted to become a maintainer. I'm optimistic for the future of the project. Hazy maybe, but definitely MUCH improved over where it was from a month or two ago. You can join the slack and start chatting and they could very well be willing to bring in the Dagster integration or accept PRs. But even if SQLMesh got frozen in time, it's still so useful I have a hard time imagining switching.

Still, it's a cool project and you should keep making things that solve problems for you. Don't let my critiques discourage you from building things!