- Do you install database on your machine (like, on macOS), use a real online one (albeit, maybe temporary), like MongoDB Atlas, or use temporary alternative (like SQLite)?
- Do you snapshot, perhaps to rollback database schema, if necessary? I find this convenient with SQLite and Git, but what are professional alternatives?
- How do you migrate development database to production database? Schema-only, or with records? Is ORM necessary or sufficient?
Pacharapol Withayasakpunt
Posted on
How do you plan your database in development, before migrating to production?
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (5)
My approach is to use Docker to run an instance of my database server locally.
The idea is to keep my local and prod DBs in sync, but for the local one to be easily destroyed and recreated.
For this I use schema migrations. I've created a project in which I leverage ActiveRecord migrations to keep my DBs in sync (whether they belong to ruby apps or not).
That way I can go up or down in specific changes, both in prod and dev, or simply redo my local one. You could do the prod one as well, but not recommended.
Hope it helps
Like Ron, I use a Docker image. It's the easiest way to keep the same config in all your environment.
I only do snapshots to keep a version of my database in case of crash, and store it in a S3 bucket in AWS.
About migrate your development DB to prod, it will depend on your case and your project. Generally, I only migrate schemas manually.
I hope it will help you
systemctl enable/disable/start/stopif not using any service/ not required.My scenarios mostly include users under 1000 in numbers. Of which daily users may be under 100. Of course, I may need to change if more number of users are active.
knex migrations are very good as tou have good control over the updates. but they need test before getting to prod. and still doing a backup is to be save. you never want to need it.
thanks