gistfile1.txt

1. PG-native master-slave achitecture
    1. Configure bindings and nodes on Both DB servers
        a. Select staging DB as the master (main)
        b. Set the prod DB as the slave node (aux)
    2. PG automatically propagates and syncs the data between the DBs
    3. Add or change data on the staging DB
        a. Compare both dataset
        b. Update records across both databases to ensure consistency
    
    PROS
    1. Data migration and eventual consistency
    2. Changes to the data managed by your PostgreSQL server happen only within transactions. 
    The server basically reads data into memory and modifies it during the transaction.
    
    CONS
    1. Not DB agnotic. Can only happen between PostgreSQL databases
    2. Most configurations are manual and might require manual tweaks to the VM and DB servers

2. Leverage Django's existing DB migration tools
    1. Creat a script automating the following data migration steps
        a. Dump the staging DB structure
        b. Dump the staging DB objects (rows)
        c. Connect to the production DB
        d. Migrate the staging DB structure dump to the production DB
        e. Insert the staging DB objects dump into the production DB
        f. Exit
    2. Update the app bootstrap/startup workflow such that:
        a. Push code to the staging server
        b. Ensure that changes to the staging DB are updated
        c. Run step 1 above
        d. Continue with normal app startup sequence
        e. App starts running on staging
        f. Push to production
        g. Ensure that changes to the production DB are updated
        h. Continue with normal app startup sequence
        i. App starts running on production
        j. Exit

    PROS
    1. DB agnotic. Could still work even if you have different database types across servers
    2. Tweaks are easier since most changes will be leveraging Djnago's internal tools

    CONS
    1. Slow
    2. Might need to be tweaked each time we use it.