Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

doc: How to migrate from pgvecto.rs to VectorChord #101

Open
VoVAllen opened this issue Nov 19, 2024 · 3 comments
Open

doc: How to migrate from pgvecto.rs to VectorChord #101

VoVAllen opened this issue Nov 19, 2024 · 3 comments
Assignees

Comments

@VoVAllen
Copy link
Member

No description provided.

@mertalev
Copy link

Related to this:

  1. Will there be an expected version of pgvecto.rs when migrating to VectorChord? For instance, will it expect 0.3 or 0.4, or would 0.2 be enough?
  2. We were thinking about whether we should support 0.4 given VectorChord will be ready soon, as it's an additional upgrade path that could maybe make the migration more complicated. Do you think this is a reasonable concern, or is it unlikely to be an issue?

@VoVAllen VoVAllen self-assigned this Nov 22, 2024
@VoVAllen
Copy link
Member Author

VoVAllen commented Nov 22, 2024

@mertalev The migration path might be more robust, but need some extra steps. The suggested way would be:

  • DROP all pgvecto.rs indexes
  • ALTER all vector columns to real[], so no longer dependency on pgvecto.rs for the whole database
  • DROP extension pgvecto.rs
  • INSTALL VectorChord+pgvector (Or change to the docker image with it)
  • ALTER all vector columns to vector type of pgvector
  • CREATE INDEX

And the first two steps should be able done with a SQL function, but need to be done at the old version. This is to eliminate dependency on pgvecto.rs so 0.2 should also work.

I think we're not ready yet and need several tests in the coming week. Target to be ready at Christmas

@mertalev
Copy link

Thanks for the explanation! That migration path sounds version-agnostic.

We're not in a big rush to upgrade, so just make it known when you think it's ready. The only constraint we have is that we plan to go stable in the first half of 2025 and would like to do the migration before going stable to get it out of the way.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants