history retention, dev-staging-production strategy?
hello. I just signed up for neon db and tried to use it. I have experience using mysql, and I am new to using postgres.
This is the operating scenario when using neon db I think.
— Production db is trying to use compute exclusively - Is there any impact on production performance even if staging db and production db are used within 1 branch? Does it dynamically increase usage because it is serverless?
The branch utilization environment of the production db is,
Perhaps static development will work on the staging db,
If we need work such as bugfix hotfix, the development team will use the branch function.
— Staging db is going to set up and operate one database for development use, and it seems that the development team will create additional branches if necessary.
history retention 7 days? - How exactly does it work, what are the operating scenarios for each condition?
After 7 days of the db created by branch, is the child branch db value initialized? Are OR maintained?
In the db created by branch, is the child branch db value maintained even after 7 days?
Is it better to create a separate project for staging?
Having a branch in the db, I can’t anticipate exactly how to set up devops. It would be nice if you could tell us the best practices for operating dev-staging-production.
I don’t want to urgently change neon db’s development environment settings while the service is running… .
Sorry I couldn’t get back to you sooner. We published this guide on our blog, which covers Neon’s object hierarchy. I think you’ll find it useful.
Production db is trying to use compute exclusively - Is there any impact on production performance even if staging db and production db are used within 1 branch? Does it dynamically increase usage because it is serverless?
Multiple databases on the same branch will share the same compute resources since you’d be connecting via the same endpoint. If you’re using autoscaling (available on the Pro plan), then the compute endpoint will automatically scale up/down based on the workload. If you’re using a fixed-size compute then you might find that the performance on the production database is impacted
We recommend the pattern of creating a branch for every environment. You can create a branch for production/staging/for every developer if you’re working in a team setting. Is there are reason why would prefer having multiple databases on the same branch?
history retention 7 days? - How exactly does it work
Neon retains a data history in the form of Write-Ahead-Log (WAL) records, which allows you to restore data to an earlier time. The data history window is 7 days. This means you can create a branch from a previous point in time and restore your data to a previous state.
In the db created by branch, is the child branch db value maintained even after 7 days?
When you create a branch, all data is copied to the newly created branch. This includes schema, data and roles. The data is maintained even after 7 days
Having a branch in the db, I can’t anticipate exactly how to set up devops. It would be nice if you could tell us the best practices for operating dev-staging-production.
It depends on your setup. If you can share more details I’d be happy to help.
We recently released a CLI that can be used in CI/CD pipelines. It enables you to easily manage Neon resources (e.g. branches, databases, etc.) Neon CLI - Neon Docs
