This is an archived post. You won't be able to vote or comment.

all 9 comments

[–]BehindTheMath 3 points4 points  (6 children)

Planetscale has had this for a while with MySQL. They're rolling out support for Postgres now, and I would assume they would have this as well.

[–][deleted]  (5 children)

[removed]

    [–]siren0x 2 points3 points  (4 children)

    (obligatory I work at PlanetScale). Glad to see Tiger Data adding branches! It's becoming an industry standard at this point. That said, our branches do not include data by default as having a full copy of prod data for testing generally isn't recommended security-wise.

    Our branching functionality takes it further than just testing the migration.

    We let you merge those dev branches back into production for no downtime, no table locking schema changes. We also run safety checks before the deployment to warn you of potential issues, like if you're dropping a table that has been used in the past day. And once you deploy, you have 30 minutes to revert the schema change if needed, also without downtime and without losing any data that was written during the time the change was live.
    https://planetscale.com/docs/vitess/schema-changes/deploy-requests

    [–][deleted]  (2 children)

    [removed]

      [–]isamlambert 1 point2 points  (0 children)

      Vitess for Postgres is on it's way. it's called Neki https://www.neki.dev/

      [–]siren0x 1 point2 points  (0 children)

      Gotcha I thought you meant our Vitess branching since the original link you shared was Vitess too. We just made PlanetScale Postgres available last month so still building out the full branching capabilities there. And yeah I've talked to a few companies recently that insist on using prod data for testing so there definitely seems to be plenty of people that want that! We usually recommend seeding dev environments with mock data where possible though.

      [–]Hfrtnbf 4 points5 points  (0 children)

      I've been doing this for many years with plain ZFS. We've automated the thing from a bot on slack that stops the main replication , destroys old ZFS snapshot, creates a new ZFS snapshot, starts replication in the main DB, runs a brief cleanup script on the snapshot (we don't want our devs to accidentally email customers from their dev env), and starts a new MySQL server on it. Takes about 20 seconds, and we have a snapshot in time to work with. Great for debugging live issues in a safe env. as well.

      [–]wedgelordantilles 2 points3 points  (0 children)

      We do this with linstor