drizzle-kit push is the most underrated feature, get on par with Atlas and add a preview/dry run

[205g0]

Atlas will show you the changes it is about to make to the database upon applying the updated schema. Check: https://planetscale.com/blog/declarative-mysql-schemas-with-atlas-cli

Offer the same for drizzle-kit push, it's paired with a branching DB provider like Planetscale so much better than the migrations work-flow. So, don't forget this feature.

Right, now I don't fully trust Drizzle to do the changes properly, so a preview would help!

[AndriiSherman]

Yeah, we can list down all statements to execute. It should be easy. Right now drizzle just notifies about possible data loss. And it was done taking in mind, that push will be used for local development only(or PlanetScale dev branches)

[205g0]

Great and yeah, you have to make users aware this should happen with dev branches only. With PlanetScale you push to dev only and then let PlanetScale do the final deployment from dev to main where PlanetScale is super strict anyway and disallows
many things, warns and blabla. And, pushing to the main db is turned off too.

I just grokked this workflow and it's SO MUCH better than old migrations and you can still travel through time, e.g., you go back 100 git commits (e.g. for a git bisect), just branch main to dev on PlanetScale and drizzle-kit push and BAAM, app and db are back 100 commits back. Try to do this with stinkin' old migrations haha.

[205g0]

FWIW, the same feature implemented by Prisma: https://www.prisma.io/docs/guides/migrate/prototyping-schema-db-push

They also advertise is on their landing page in one bullet but they might not realize how powerful this feature actually is. Here, https://www.prisma.io/docs/concepts/components/prisma-migrate/db-push#choosing-db-push-or-prisma-migrate they stress it's only for development and fast prototyping but forget or don't know that you can fully use it without any migrations if you have a db hoster with branching (which most new providers offer). So, they still emphasize that you do not need migrations which is just half of the story.

I think, as long as every schema change in the schema files is commited to git, all is good and nothing more is needed. Prisma's list "not recommended" list is wrong here when saying you can't track changes over time.

I find, Atlas CLI prompts to be better, they show the changes as raw SQL and not some verbal, vague summary.

Edit: In TypeORM this feature is called sync, here https://typeorm.io/sequelize-migration#schema-synchronization
But I think, it's syncing all-the-time, it's not called explicitely, not sure though

[AndriiSherman]

Yeah, this feature is good only for local schema prototyping or PlanetScale(for now as a service to provide schema migrations for you)
In all other cases and for production-grade applications you need to use migration files approach

[205g0]

Yes, but look: PlanetScale, Neon/Vercel Postgres, Xata, Tigris--all have branching and more are coming. So, once the hoster has branching, there's no need for daddy's migrations anymore:

1. You branch from main to dev
2. You can drizzle-kit/prisma/atlas push whatever you want to dev; then on dev, you can destroy everything, drop all tables, whatever you like; the great thing is, you see in real-time the changes on dev; and if you mess up, just delete dev and branch again from main and repeat
3. Once happy, you git commit the new schema file and start a deploy request from dev to branch which is handled by PlanetScale et. al..; and latter doesn't use any migration files either; you could ofc avoid PlanetScales deploy workflow but then would need to apply migrations to production from you local dev env, this is much more risky and/or permission managerment to production is more complicated; bonus: PlanetScales's diffing is more restrictive, e.g. blocking changes are not allowed (need to be done with ghost tables), so it cannot happen that a junior dev applies a huge blocking migration to proudction leading to minutes of downtime

I agree that we still need migrations and the market won't adapt that fast. But it's also an opportunity, because this push feature isn't trivial either, look how many security checks PlanetScale does; e.g. you can't rename a table and have to do this in multiple steps; you guys are smarter and ask if it's a rename or drop (I think in the migrations tools) and Prisma doesn't do this. So, there's a lot of potential to make this feature right and also to educate the market. Everybody talks about branching but really no one gets this feature--it took me around a month to fully get it (which was 2h ago).

IDK, maybe I'm missing something but the traditional migrations workflow with its gazillions migration files is so much more cumbersome and inflexible, I mean time travel is just not possible or did you ever rolled-back 100 migrations just to do a git bisect? Good luck haha.

This is the future! 🚀

[atanaskanchev]

Is push available for Postgres yet?

[tehnrd]

It's working for me!