undefined | Better HN

0 pointstoomanybeersies7y ago0 comments

We had to do something similar at my old job, but rather than migrating to a different schema, we were migrating our moderately sized DB (tens of gigabytes) from MySQL to Postgres.

We dual wrote to both DBs while we copied the existing data to the new DB, then switched them over. I think we had less than 5 minutes of downtime all up.

0 comments

y4mi7y ago

tens of GB is tiny though.

most production systems are at least a few hundred gb, and the previously mentioned scaling problems from foreign keys and constraints are pretty nonexistent unless you're starting to push the boundaries of normal ACID DBs.

i.e. a few TB of data with at least thousands of queries per second and lots of writes/updates

j / k navigate · click thread line to collapse

0 pointstoomanybeersies7y ago0 comments

We had to do something similar at my old job, but rather than migrating to a different schema, we were migrating our moderately sized DB (tens of gigabytes) from MySQL to Postgres.

We dual wrote to both DBs while we copied the existing data to the new DB, then switched them over. I think we had less than 5 minutes of downtime all up.

0 comments

y4mi7y ago

tens of GB is tiny though.

i.e. a few TB of data with at least thousands of queries per second and lots of writes/updates

j / k navigate · click thread line to collapse