<p>No, running <code>composer update</code> will not – by itself – result in any changes to your database.</p>

<p>When you run <code>composer update</code>, all that happens is that Composer downloads updated versions for all your installed packages (i.e. Craft, plugins and other dependencies), before writing a manifest of your currently installed packages to the <code>composer.lock</code> file. Full stop; Craft isn't actually involved in this process at all.</p>

<p>However, sometimes an updated version of Craft (or a plugin) might need to change something in the database, in order to function. This is called a "migration", and is distributed with the package in question as a "migration file", containing the database queries necessary to perform the update that the new version of the package needs. <strong>In terms of updating core code or plugins, running these migrations is the only thing that will end up actually updating your database.</strong> You do have to run them at some point, because if there are pending migrations on your site's file system (i.e. migrations that have been downloaded but not run yet) your site will be <strong>unavailable</strong> until those migrations have been run (important – note that if you're updating Craft or a plugin through the Control Panel and not using the command line/Composer directly, Craft will attempt to auto-run any migrations for you, after Composer finishes downloading the new packages).</p>

<p>There are two ways to run pending migrations:</p>

<ol>
<li>Visit the control panel in a browser, and click the prompt(s)</li>
<li><p>Execute the following from your command line (this should be run from the root directory for your project, i.e. where your <code>composer.json</code> file resides):</p>

<p><code>./craft migrate/up</code></p></li>
</ol>

<p>The above command is safe to run even if there aren't actually any migrations pending, so if you're writing some sort of update/sync script, it could easily be tacked on at the end to make sure that any pending migrations that might be included with the updated code, are run (if you sync up the database instead, this won't be necessary as long as you've run the migrations locally).</p>

<p>In addition to the above – while your strategy for keeping Composer dependencies on the live server updated certainly works, it seems a bit unnecessary and/or convoluted to have to sync the database from local to production. I'd advise to either just run the migrate command in case there are migrations, or even follow what is generally considered the best practice for dealing with Composer dependencies: don't commit the actual dependencies (i.e. your <code>/vendor</code> folder) to version control, only the <code>composer.lock</code> file, and run <code>composer install</code> <strong>on the server</strong>, after the latest version has been deployed. Here's how a very simple deploy script could look:</p>

<pre><code>cd /path/to/host/root
git pull origin production
composer install --no-interaction --prefer-dist --optimize-autoloader
./craft migrate/up
echo "" | sudo -S service php7.0-fpm reload
</code></pre>

CC BY-SA 4.0
2018-07-13T19:44:47.137Z
Great. I edited the answer to include an important notice that if you're updating core or plugins through the Control Panel, Craft will run migrations (and consequently, update the database) automatically, unlike updating via Composer where you'll need to run them manually one way or the other.
Mats Mikkel Rummelhoff
CC BY-SA 4.0
2018-07-13T13:48:34.620Z
2018-07-13T19:43:37.097Z
2018-07-13T19:43:37.097Z
Mats Mikkel Rummelhoff
<p>When creating plugins on my local I need to run composer update to make sure everything is in sync. In order to make sure the client has the same vendor and plugin folders, I then upload them to the server.</p>

<p>I just want make sure that when running <code>composer update</code> that Craft does not make changes to the database. If so, I need to make sure I also send the latest database to prod as well.</p>

<p>We've made a cli tool to easily sync environments, and I would like to add a command that takes care of this edge case as well.</p>

<plugin-development><composer>
Does composer update make changes to the SQL database
# Does composer update make changes to the SQL database

(Asked by: username_0 on 2018-07-13)

When creating plugins on my local I need to run composer update to make sure everything is in sync. In order to make sure the client has the same vendor and plugin folders, I then upload them to the server.

I just want make sure that when running `composer update` that Craft does not make changes to the database. If so, I need to make sure I also send the latest database to prod as well.

We've made a cli tool to easily sync environments, and I would like to add a command that takes care of this edge case as well.

**Tags:** plugin-development, composer


---

## 1 answers

### Answer by username_1 on 2018-07-13. Score: 5 | Accepted answer

No, running composer update will not – by itself – result in any changes to your database.
When you run composer update, all that happens is that Composer downloads updated versions for all your installed packages (i.e. Craft, plugins and other dependencies), before writing a manifest of your currently installed packages to the composer.lock file. Full stop; Craft isn't actually involved in this process at all.
However, sometimes an updated version of Craft (or a plugin) might need to change something in the database, in order to function. This is called a "migration", and is distributed with the package in question as a "migration file", containing the database queries necessary to perform the update that the new version of the package needs. In terms of updating core code or plugins, running these migrations is the only thing that will end up actually updating your database. You do have to run them at some point, because if there are pending migrations on your site's file system (i.e. migrations that have been downloaded but not run yet) your site will be unavailable until those migrations have been run (important – note that if you're updating Craft or a plugin through the Control Panel and not using the command line/Composer directly, Craft will attempt to auto-run any migrations for you, after Composer finishes downloading the new packages).
There are two ways to run pending migrations:

Visit the control panel in a browser, and click the prompt(s)
Execute the following from your command line (this should be run from the root directory for your project, i.e. where your composer.json file resides):
./craft migrate/up

The above command is safe to run even if there aren't actually any migrations pending, so if you're writing some sort of update/sync script, it could easily be tacked on at the end to make sure that any pending migrations that might be included with the updated code, are run (if you sync up the database instead, this won't be necessary as long as you've run the migrations locally).
In addition to the above – while your strategy for keeping Composer dependencies on the live server updated certainly works, it seems a bit unnecessary and/or convoluted to have to sync the database from local to production. I'd advise to either just run the migrate command in case there are migrations, or even follow what is generally considered the best practice for dealing with Composer dependencies: don't commit the actual dependencies (i.e. your /vendor folder) to version control, only the composer.lock file, and run composer install on the server, after the latest version has been deployed. Here's how a very simple deploy script could look:
cd /path/to/host/root
git pull origin production
composer install --no-interaction --prefer-dist --optimize-autoloader
./craft migrate/up
echo "" | sudo -S service php7.0-fpm reload

> **Comments:**
> **username_1**: Great. I edited the answer to include an important notice that if you're updating core or plugins through the Control Panel, Craft will run migrations (and consequently, update the database) automatically, unlike updating via Composer where you'll need to run them manually one way or the other.  

---

