Q:

What kind of granularity is better for migration? 

Here is my case:
There are several tables: users, addresses, comments, posts. 
My confusion is what kind of granularity is better for migration? 
I can put all DDL in one migration file and one seed file, like below:
migration:
npx knex migrate:make create_all_tables
seed:
npx knex seed:make all_tables
Or, separate them, create migration file and seed file for each table?  
migration:
npx knex migrate:make create_users
npx knex migrate:make create_addresses
npx knex migrate:make create_posts
npx knex migrate:make create_comments
seeds:
npx knex seed:make users
npx knex seed:make addresses
npx knex seed:make comments
npx knex seed:make posts
Any ideas?  thanks. 

A:

Just create all the tables in a single migration file unless you have some specific use case why you would like to separate those creations to separate files.  You will like to keep number of migration files as low as possible. 
Usually you will later on add one migration file per one pull request that adds a new feature to the app (in case if there are any changes in schema).  Once migration is created it should never be modified later on, except if you are still in initial implementation phase and don't have any server running production database yet. 
For seeds generally I recommend granularity of complete data sets with single seed command, which adds some useful set of initial data for testing (I would not actually use seed files at all, but I would just wrote some API that test framework uses to add easily some initial data to DB after truncating all the tables). 
PS.  one more anti-pattern I see a lot is cleaning up test database by rolling back schema and then running migration again.  You should initialize database and run migrations just once when test suite starts and afterwards between tests you just truncate all tables and id sequences and populate DB again with initial data set.