Migrating from Pixelfed

There is no data migration, because there is no data to migrate. GrainFed opens the database Pixelfed was already using. What follows is a sequence of checks around one small, deliberate moment of downtime.

What does not change

• Your accounts. Same rows, same signing keys, same followers, same URLs. Nothing re-federates and nobody re-follows.
• Your media. Same files, same paths, same bucket.
• Your logins. Existing OAuth tokens keep working, so mobile clients stay signed in across the switch.
• Your schema. GrainFed never ALTERs a Pixelfed table. Its own tables are gf_-prefixed and Pixelfed has never heard of them.

The five phases

Everything is dry-run until you pass --apply. Everything before cutover is reversible, and cutover is deliberately the smallest step — all the expensive work happens before it.

grainfed adopt --phase inspect
grainfed adopt --phase prepare --apply
grainfed adopt --phase cutover --apply
grainfed adopt --phase verify

Giving it back

Reverting is a supported operation and not an emergency procedure:

grainfed adopt --phase revert --apply

It stops GrainFed, restores what the baseline recorded, and starts Pixelfed again. Because no Pixelfed table was ever altered, Pixelfed finds the database it expects. Posts made while GrainFed was running are ordinary rows in the ordinary tables, so they are still there.

If you want the gf_* tables gone too, --revert --purge drops exactly the ones adoption created, by name, and leaves alone any that predate it.

Then make it faster

Adoption deliberately leaves the schema exactly as Pixelfed had it. That is what makes dropping GrainFed in — and taking it back out — possible. Optimisation is a separate step you run when you are ready, and can re-run later as the project learns about more:

grainfed optimize            # report; changes nothing
grainfed optimize --apply    # make the changes
grainfed optimize --revert   # put them back exactly

It only ever changes indexes — never a column, a row or a table. An index changes how fast a query is answered and never what it answers, so an instance that never runs this is correct and merely slower, and Pixelfed keeps working against a schema that has run it. Every change is recorded before it is made, together with the statement that undoes it.

On the first instance it ran against, it found 37 indexes that could never be chosen — each one a leading prefix of another index on the same table, written on every insert for nothing — and two worth adding.

Things worth knowing first

• Pixelfed's job queue must be empty. A queued job is work Pixelfed intended to do and GrainFed will not; adoption refuses to proceed while any remain.
• Your APP_KEY must be intact. It decrypts sessions and several config values. An instance whose key has been rotated without re-encrypting is not adoptable, and inspect says so.
• Check your database's memory settings. Instances migrating from a stock install are frequently running MySQL's default 128 MB buffer pool against a database several times that, which makes everything feel slow regardless of which server is in front of it. Settings → Status reports it.