[philipkimmey]

Rows, not columns. But more so than really large tables, I find MySQL will tip over even on smaller tables, not very hot tables, if I want to do the work without downtime.

(It may well just be my environment, but it is fairly standard RDS on AWS.)

[jcoby]

It's a limitation of MySQL unfortunately. MySQL does schema changes by creating a new table with the new schema and copying the old data into it and doing an atomic switch over. The table gets locked for obvious reasons.

Percona has pt-online-schema-change [1] but I have no experience with it or if it works on RDS.

There are other solutions. The most simple is doing the table rewrite yourself (but risking losing data). The more complex is to have a buffer/queue that can hold requests until the migration completes but this only works in certain specialized situations.

I'd love to find a better solution to migrations in MySQL. I've had migrations take 15 minutes on a relatively small table (2M rows). I'm a little scared to try pt-online-schema-change for fear of corrupting the db.

I would switch to PostgreSQL (nothing but love for that database from me) but the ORM I'm using has issues with identifier quoting and I can't use my "user" table with it.

1: http://www.percona.com/doc/percona-toolkit/2.1/pt-online-sch...

[philipkimmey]

We were using PGSql at the beginning of this project, but I was lured by the automatic backups / restore capabilities that RDS provides and I migrated.

One of my co-workers used to pound on PGSql pretty hard in a very high traffic environment and has nothing but good things to say, but I'm not crazy about the idea of having to learn all of PGSql's foibles like we have MySQL.

My impression is that MySQL 5.6.x (we're on 5.5.x) should help with the schema migration pain, but I don't have any hard evidence for that claim.

My hope is that MYSQL 5.6.x will remove a lot of the pain, but I don't have a