📜 This table has the history of migrations that have been run and what state they ended up in.
In the happy path, we get a migration that applies without issue.
But what happens if a migration fails to apply? In that case, we need to use `prisma migrate resolve`. We have a migrations folder that keeps the history of changes to our database schema and has the SQL files for replaying all the changes to come to the current shape of the database.
But there's another spot where migrations are tracked: the `_prisma_migrations` table. 
`prisma migrate deploy` is what we want to have run along with our app deployments so that any pending migrations get applied to our target databases.
👉 This is typically not a command that you'll work with much in local development. We generally use `prisma migrate dev` when we're in development working against our local (or remote) development database.
When we want to deploy our changes to production, we use another command in our CI/CD or deployment pipelines: 
This command will do the following:
✅ Add a new migration file in the `prisma/migrations` directory
✅ Execute the SQL in the generated file to apply the change to the database 
Let's say we are starting out with a brand new app and a fresh database.
We've got our first model and now we want to turn this into a table in our database.
We also want to have a SQL file that produces this change.
We can get these two steps done in a single command 
📊 The most robust way to manage changes to your database schema over time is with migrations.
Prisma Migrate makes this super simple ✅
Let's have a look at some of the most common commands you'll use with Prisma Migrate 👇 
The work that @marekfort.bsky.social has done here is quite impressive 🤯. And the best of all is that you can plug it into:
• Xcode projects
• Tuist-generated projects
• Swift packages
And thanks to smaller file-system footprint, CI caching becomes faster. 
If you use SwiftPM – and it doesn't matter if you use our generated projects or not! – you might wanna check out the new Tuist Registry to improve your project's dependency resolution. We truly believe this can become an essential piece in any Swift developer's toolchain ☺️
If this all sounds intriguing, head over to our docs and take it for a spin: docs.tuist.dev/en/guides/de... The Tuist Registry would not have been possible without the amazing Swift community. We both depend on the Package Registry Service accepted and implemented in Swift 5.7, the amazing Swift Package Index as a source of open source Swift packages, and the Tuist community. So, _thank you_ 💜
However, when you use the Tuist Registry, SwiftPM communicates with our servers and only serves you the versions you need. The amount of data that needs to be transferred and stored on your disk is smaller by up to 90 %! We've seen projects going from 6 GB to 600 MB for their dependencies folder.
So, what _is_ Tuist Registry? It's a centralized place for open source Swift packages. The current status quo with SwiftPM is having to do deep clone of _every_ dependency that you might need. That can be slow, inefficient, and unreliable.
We have also recorded a video walkthrough, so you can see the Tuist Registry in action: videos.tuist.dev/w/6pSq8dstTG... The Tuist Registry is _out_: tuist.dev/blog/2025/01... 🔥📦
Want to make your SwiftPM resolutions more reliable, efficient, and faster? Then you might want to have a look 👀
Oh, and we shouldn't forget to mention – this feature is available for _anybody_, regardless of your setup. "Welcome to the company we really need you to optimize our database queries"
Say no more 
🤫 Prisma Studio is getting some small changes that will bring BIG improvements to your workflow.
Tune in Wednesday, January 29 to find out what's coming 👀 
TIL htop can also show zfs arc stats
hahaha 🤫
nice one!
Nah just running a big Postgres instance!
👀
your ryzen doesn't have to know 😏