I think it makes sense, anything that helps with schema.rb flip-floping is welcome, but:

• I'm not sure if it should be even be an option?
• If it's an option it probably should be part of load_defaults
• I think I'd like a second opinion, as it's a big user facing change. @matthewd or @dhh perhaps? Feels like it something you'd care about.

I also wonder if ignoring the column other could result in bug. I think as long as you use higher level Active Record APIs you're fine, but there might be some really intricate cases where code is dependent on columns ordering?

@fatkodima i saw your change to reduce merge conflicts in schema #53797 and wondering what you think about the change I have here. Have you noticed issues with columns changing order in the schema.rb and would the change I've made here help your team with that? Happy to make changes here too if you had suggestions.

#53797 is about structure.sql, not schema.rb.

I didn't get some other opinion, but I think this change is OK. It just need to be added in load_defaults, have doc in configuring.md and all that.

@byroot ah, sorry, I misread the PR and didn't look at the diff itself.

I'll update with those changes and then ask for another review, thanks!

Sorry for the delayed reply 😅

Yeah, I worry partly about the pluck("*") case ¹, and partly about people who've used MySQL's ADD COLUMN .. AFTER .. syntax to be very conscious of their column order... but mostly just the aesthetic loss: most of the time, most tables' most important columns all appear together, in a semi-intelligent cluster, at the start of the list (because they were added first, and in groups). And even ignoring the affect on DBs populated by future schema loads, this file is itself generally the human reference point for what columns [and thus attributes] are available on tables/models.

@matthewd thanks for the feedback, I kind of worry about that too but I also think it's already happening and people just ignore those diffs. Either way I'll make it something that can be disabled so that people can opt out of it if they want.

This should not be an option. This should just be default behavior. Schema dumping should be deterministic regardless of the platform.

@dhh sounds good! Just updated the PR to remove the option and always sort the columns when dumping. If you want any other changes let me know.

I rebased your branch because it was quite outdated. I also added a changelog entry, I'll merge on green.

Thanks @byroot!

Agree there's no need for a separate option here: this can easily be left to the category of low-level schema details where, if you need to reproduce your database more precisely than our schema dump, that's what the structure.sql dump is for.

Hi! I wrote the original fix-db-schema-conflicts gem to solve this problem 11 years ago.

Over time we ended up adding several other sorts:

• columns
• extensions
• foreign keys
• indexes

Should we add sorts to those other things too?

@jakeonrails I had looked at a few of those when I made my change and it seemed like indexes and foreign keys were already sorted. Feel free to take another look though in case I missed something (I didn't look at extensions). Since we're doing columns now I don't see any reason not to do the others.

Hmm… so I wanted to write up a PR with a bug fix since I discovered the schema re-sorts my table columns, but I've found this was changed on purpose…

The description says this adds an option to change the behavior like this - I would strongly vote against making this non-configurable, otherwise I think I'm just gonna have to monkey-patch this method. I want my table columns to be in the order I specified, not alphabetical. Yes, this makes the order deterministic, but it's now deterministically *wrong* ¯\_(ツ)_/¯

If this stays non-configurable, then I think you'd also need to remove support for after / before column options in migrations? Because otherwise they just don't work if schema overrides whatever you put there anyway…

Ordering column in the table is a known performance optimization in postgresql

https://www.percona.com/blog/postgresql-column-alignment-and-padding-how-to-improve-performance-with-smarter-table-design/

This PR appears to diverge from the original proposal. Ideally, sorting columns alphabetically in schema.rb should be an optional behavior. After nearly two decades of allowing this flexibility, introducing a new default standard raises concerns.

For many developers, the order of columns in relational database tables is more than a stylistic preference. It often serves practical purposes. While some ordering choices are subjective, consistent patterns can significantly improve readability and workflow efficiency.

For example, I find it helpful to place foreign keys at the beginning. Knowing that id will always be the first column, and that created_at and updated_at will appear last, provides a predictable structure. Similarly, when reviewing address-related records, having fields follow a logical sequence — zip code, street name, number, neighborhood, city — makes navigation easier and reduces cognitive load.

Altering this established behavior could be seen as a step backward for many users who rely on this structure for clarity and productivity. It may be worth reconsidering whether enforcing alphabetical sorting by default is necessary or whether it could remain configurable to accommodate different workflows.

FYI, I have a PR here adding an option to restore the previous behavior of the dumper, I rebased it now on the latest version: #55414

A real world example: we interact with customers that dump CSV files from their databases using a SELECT *. This is a breaking change as the development environment no longer reflects the production environment and different results are produced.