Setup Production Database

[00:00:00]
>> Speaker 1: All right, so we want to get this live, so somebody else other than us can actually interact with it, and I decided to deploy this to an app called Render.com, which is kind of like these Heroku vibes, but before Heroku got, I don't know, I don't know what happened to them, but it's kind of a really great platform for deploying things very easily

[00:00:00]
There are other options out there like Railway, and you've got your JAMstack serverless folks like Vercel and Netlify and Cloudflare, and Fly.io You've got so many of those companies—they all do different things, but Render just seems like the simplest, easiest way to get started from my experience

[00:00:00]
That doesn't mean it's the best; it was just the easiest and makes the most sense They all have the same logic, and then you can go a little closer to the metal with AWS, Google Cloud, Azure, or Digital Ocean If you want to get closer to the metal, you can do that too

[00:00:00]
There's just no reason to do that when these services exist until you start trying to save money, in my opinion So we're going to use Render And these are some things we need to do before we get deployed, so we're going to go through our pre-deployment checklist

[00:00:00]
First, you're going to create another database You're going to create a third one because we have a local one, we have a testing one, now we need a production one If we were making a staging environment, you'd make a staging database If you had a bunch of people on your team, you might make one for each person, or you can do that dynamically with database branching

[00:00:00]
We're going to make another database It's super easy We've done this before, so we'll go back to Neon Launchpad and click this button again Remember, these only last for 72 hours unless you claim it, so if you start getting errors 72 hours from now on your deployed app, that's why—go make another database or claim it and make an account

[00:00:00]
I've created it and will keep note of it for now What we're going to do now is a one-off thing because the production database we created doesn't have our schema If we try to deploy right now, even with the correct production database URL, it would break because the database has no idea what our schema is

[00:00:00]
So we have to run the initial migration Up to now, we've been using `db push` in development to force our schema to the developer database For the production database, we can't do that—we have to create a proper migration We need to generate a migration first, which is the diff of the changes we want

[00:00:00]
Then we'll apply that migration to the database We'll do this locally The simplest way is to take the new database URL, go to your `.env` file, comment out the local database URL, and set it to the new production database URL Then you'll run `npm run db:generate`

[00:00:00]
This command doesn't interact with the database—it just looks at your schema and generates the SQL migration file It creates a file in the migrations folder I've created the first migration, and you can see the files in the migrations folder The migration files include a meta folder with a journal and a snapshot.json, which is essentially a JSON representation of your schema

[00:00:00]
The SQL file is the migration that Drizzle generates for you automatically—something you'd have to write manually with other ORMs like Prisma Note that migrations have numbers to ensure they're applied in the correct order Sometimes developers use dates as prefixes for migrations

[00:00:00]
These migrations get checked into GitHub so that everyone on the team can run them In a real-world scenario, you wouldn't run migrations directly on the production database Instead, you'd run them through a deployment script, potentially via SSH, or use specialized migration management tools

[00:00:00]
Now we'll apply the migration to the production database by running `npm run db:migrate` This will apply all migrations in order from oldest to newest After running the command, you can verify the tables in the production database using `npm run db:studio`

[00:00:00]
Important note: Quickly remove the production database URL from your `.env` file and restore the local database configuration Never force push a schema to a production database, as it can potentially destroy existing data Always use proper migrations for production databases.