3 ms·

I don't think I would be comfortable doing database schema related work in a branch unless I was also essentially branching my database at the same time. Even

I don't think I would be comfortable doing database schema related work in a branch unless I was also essentially branching my database at the same time. Even for my mostly garbage personal developer database that's filled to the brim with nonsense names and keyboard mashing. The chance of breaking something and wasting a large amount of time and data are too great. Of course, Thou Shalt Have Backups, but it's not exactly a frictionless experience if you fry things and have to go back to them. Unfortunately it's not quite as quick and easy to clone off a copy every time you want to run some tests or fiddle with a spike as it is to jump between Git branches.

paloaltokid 8y ago
> branching my database This sounds like a great product idea! Someone please do this. :)
- isotropy 8y ago
  Check out Delphix (https://www.delphix.com https://www.delphix.com). It provides a ZFS-backed copy of your production database per developer using snapshots, with rollback. Disclaimer: a friend worked there, I haven’t used it personally, and it’s not free.
mmt 8y ago
> Of course, Thou Shalt Have Backups, but it's not exactly a frictionless experience if you fry things and have to go back to them. I do wonder how much of this is because of, specifically, PostgreSQL not having enough "market" penetration. For a very long time, it's had very good unclean-shutdown resilience with the way it does its write-ahead logs and has even had point-in-time-recovery (using those same WALs, just stored longer) for several years. Combine that with a snapshotting filesystem, and that would seem like a pretty low amount of friction for recovery, without even having formal backups. If your database is big enough, you need a certain amount of performance out of it, or you need it to be a recent enough copy [1] of the production data (which likely means "all of the above"), then it does start to get legitimately challenging. [1] or, worse, something ETL'ed (anonymization comes to mind)
shoo 8y ago
If you have a quick script to initialise the db into some known state, and are defining all the schema changes as migration scripts, and maybe have access to something like pg virtual to stand up temporary db test environments, you could probably get pretty close to this by just version controlling all the scripts required to stand up a db and apply all the migrations. http://manpages.ubuntu.com/manpages/trusty/en/man1/pg_virtualenv.1.html http://manpages.ubuntu.com/manpages/trusty/en/man1/pg_virtua...

paloaltokid 8y ago

> branching my database This sounds like a great product idea! Someone please do this. :)

isotropy 8y ago
Check out Delphix (https://www.delphix.com https://www.delphix.com). It provides a ZFS-backed copy of your production database per developer using snapshots, with rollback. Disclaimer: a friend worked there, I haven’t used it personally, and it’s not free.

mmt 8y ago

> Of course, Thou Shalt Have Backups, but it's not exactly a frictionless experience if you fry things and have to go back to them. I do wonder how much of this is because of, specifically, PostgreSQL not having enough "market" penetration. For a very long time, it's had very good unclean-shutdown resilience with the way it does its write-ahead logs and has even had point-in-time-recovery (using those same WALs, just stored longer) for several years. Combine that with a snapshotting filesystem, and that would seem like a pretty low amount of friction for recovery, without even having formal backups. If your database is big enough, you need a certain amount of performance out of it, or you need it to be a recent enough copy [1] of the production data (which likely means "all of the above"), then it does start to get legitimately challenging. [1] or, worse, something ETL'ed (anonymization comes to mind)

shoo 8y ago

If you have a quick script to initialise the db into some known state, and are defining all the schema changes as migration scripts, and maybe have access to something like pg virtual to stand up temporary db test environments, you could probably get pretty close to this by just version controlling all the scripts required to stand up a db and apply all the migrations. http://manpages.ubuntu.com/manpages/trusty/en/man1/pg_virtualenv.1.html http://manpages.ubuntu.com/manpages/trusty/en/man1/pg_virtua...