I suspect someone is going to say to use something like the pgvector template

Hello, I am someone.

Sure that's an option but I can see a few reasons why you might not want to have to migrate your data over to another database, so initially my next idea would be to still deploy the pgvector template, but instead simply move your volume over to it, makeing sure the Postgres version deployed by the pgvector template is the same as the Postgres version of your original database.

Disclaimer, untested, please test this idea with a unimportant database with some mock data in it.

Thank you, someone :)

Is there no chance of someone manually helping me install the extension on the existing service?

I understand otherwise; will start planning to migrate over to the new service.

Is there a way I can copy the existing volume (rather than moving it), as a way to test the new service (with its newly copied volume) with my api?

Postgres is deployed as an image so it's not so much of an install as it would be to use an image that has your needed extension installed already.

Unfortunately making a duplicate snapshot of the volume is not something supported, that's why I suggested you try the idea with a database that doesn't have your important data in it to make sure the idea works.

No worries, will figure it out. Thanks for your help.

Would you be interested in written instructions on swapping the volume to a pgvector service?

Perhaps for others?

For myself, i'm going to create a new volume and a new db, and basically re-migrate and re-seed everything to it separately with the cli. In other words I won't touch the prod DB. Once that's done, i can update the API env vars to point to the new db. That's the theory anyway!

That seems like a completely different solution that what I suggested?

Okay, perhaps i could do with some instructions because i think I misunderstand your original solution. Thanks!

To test the idea -

1. Deploy a regular Postgres database.

2. Seed it with some data.

3. Deploy the pgvector template.

4. Disconnect the volume from the regular Postgres database.

5. Disconnect the volume from the pgvector database.

6. Mount the regular Postgres' volume to the pgvector service at /var/lib/postgresql/data

7. Check to see if the pgvector service works as intended.

If step 7 is successful for you, apply steps 3 and onward to your production database. But please note neither me nor Railway would be responsible for any data loss, and it's always a good idea to have a backup of the database.

Thanks Brody.

This is helpful, however i went with a slightly different approach.

I duplicated my API service changed its environment variables to connect to a new DB service (pgvector template).

Using the CLI, i updated my API application to link to the new API service, which meant I can run my migrations and seed script straight from my API application. This is okay for me because my production API doesn't support any WRITE operations, only READ, so there's no issue with data being lost during this operation.

This means that my "production" API and DB are currently on the side, untouched and unaffected.

The migration is still ongoing, and once it's done it will be simple task of updating the environment variables to point to the new pgvector db.

You can mark this as resolved now if you want.

Thanks for your help!

You started your message by telling us that it was a database with a lot of data in it, so I thought you would not want to manually migrate data, hence the idea of simply swapping volumes, but hey if it works for you then all is good!