Earlier quoted context omitted.
mysql is a bigger target market.
We recently started investing in Postgres because of support of JSON fields and nested indexes in those fields. Should we have chosen MySQL?
[deleted]
GitHub's online schema migration for MySQL
11–20 of 96 posts
Re: GitHub's online schema migration for MySQL
#12Holy crap, an alternative to Percona? Why does MySQL get two awesome tools and Postgres nothing?
There are several other notable options - SoundCloud's LHM, Facebook's online schema change tool, etc. They all have their different quirks.
(And as modern MySQL releases get better online DDL support, become less and less critical - though still useful for all of those edge cases where native lockless online DDLs can't work yet)
Re: GitHub's online schema migration for MySQL
#13Holy crap, an alternative to Percona? Why does MySQL get two awesome tools and Postgres nothing?
Postgres supports transactional DDL statements natively, and many alter table statements don't end up locking the table nearly as severely as some MySQL versions do.
Re: GitHub's online schema migration for MySQL
#14Earlier quoted context omitted.
mysql is a bigger target market.
We recently started investing in Postgres because of support of JSON fields and nested indexes in those fields. Should we have chosen MySQL?
MySQL has I think all of these features now in 8.0 off the top of my head. Having said that it was only just released to stable very recently and like all good things it may pay to wait for a few more edge cases to be flexed out.
Ultimately I’d always suggest the tool you are most familiar with if it’s doing a good enough job.
Re: GitHub's online schema migration for MySQL
#15Earlier quoted context omitted.
mysql is a bigger target market.
We recently started investing in Postgres because of support of JSON fields and nested indexes in those fields. Should we have chosen MySQL?
They both have their issues (though I think in most cases Postgres has saner defaults. Alternative distributions of MySQL like Percona Server can help improve the situation somewhat for MySQL).
Doing anything meaningfully complex or mission-critical with either will always require care, attention, and understanding of how the database is doing its work. If you know MySQL internals particularly better, it may benefit you to focus your efforts there as modern MySQL is perfectly capable (decent online DDL support, decent native JSON support, etc).
If your team aren't experts with either, I'd invest my effort in learning Postgres.
Re: GitHub's online schema migration for MySQL
#16Earlier quoted context omitted.
mysql is a bigger target market.
We recently started investing in Postgres because of support of JSON fields and nested indexes in those fields. Should we have chosen MySQL?
Probably no.
As someone else pointed out, the reason so many similar tools exist for this task on mysql and there's no such tool for postgres is not that postgres isn't as popular.
The reason is that this problem is almost non-existent on postgres as many table alterations do not lock the table.
Re: GitHub's online schema migration for MySQL
#17Earlier quoted context omitted.
We recently started investing in Postgres because of support of JSON fields and nested indexes in those fields. Should we have chosen MySQL?
Probably no. As someone else pointed out, the reason so many similar tools exist for this task on mysql and there's no such tool for postgres is not that postgres isn't as popular. The reason is that this problem is almost non-existent on postgres as many table alterations do not lock the table.
All alters require a full read/write lock, it’s just that most return instantly. This can be a problem if you have long running transactions, as the alter blocks behind all open txns and all new queries block behind that. python for instance has a very strong opinion that you should be using transactions for everything, and is much more likely to have to deal with it than say ruby.
But you’re right, my comment is mostly pedantic, that Postgres implements alters better so these tools aren’t needed.
Re: GitHub's online schema migration for MySQL
#18Earlier quoted context omitted.
mysql is a bigger target market.
We recently started investing in Postgres because of support of JSON fields and nested indexes in those fields. Should we have chosen MySQL?
fwiw, MySQL has supported JSON [1] and also allows nested indexes via functional/virtual indexes [2] since v5.7.8 (August 2015)
1. https://dev.mysql.com/doc/refman/5.7/en/json.html
2. https://dev.mysql.com/doc/refman/5.7/en/create-table-seconda...
Re: GitHub's online schema migration for MySQL
#19Back when I worked for Shopify, I got a chance to work on something similar -- GhostFerry(https://github.com/shopify/ghostferry), which allows for doing all sorts of migrations, that too between various databases.
It was recently open-sourced. Do take a look.
Re: GitHub's online schema migration for MySQL
#20This is a really amazing, very well designed and thought out, tool that solves a problem that should never exist.