Migrate from PostgreSQL to Zilliz Cloud

This topic describes how Zilliz Cloud handles data type mapping, collection naming rules, and considerations when migrating from PostgreSQL.

For index settings and post-migration steps, see External Migration Basics.

Prerequisites

Before starting your PostgreSQL to Zilliz Cloud migration, ensure you meet these requirements:

Requirement	Details
Network access	Source PostgreSQL database must be accessible from the public internet
Database access	Valid database endpoint, username, and password with necessary permissions
pgvector extension	Tables must use pgvector extension for vector data storage
Vector field requirement	Each source table must contain at least one vector field, and vector fields cannot contain null values.
Data availability	Source tables must contain data. Empty tables cannot be migrated.

Requirement	Details
User role	Organization Owner or Project Admin
Cluster capacity	Sufficient storage and compute resources (use the CU calculator to estimate CU size)
Network access	Add Zilliz Cloud IPs to allowlists if using network restrictions

Understanding how PostgreSQL data types map to Zilliz Cloud is crucial for planning your migration:

PostgreSQL Field Type	Zilliz Cloud Field Type	Description
Primary key	Primary key / Auto ID	Single-field primary key: Mapped directly as the target collection's primary key. Absence of primary key: Auto ID is enabled for the target collection to support tables without a primary key. Composite primary key: Auto ID is enabled; composite keys are treated as regular scalar fields. When migrating data, you can enable Auto ID. However, if you do so, the original primary key values from your source collection will be discarded.
vector	FLOAT_VECTOR	Vector dimensions remain unchanged.
text/varchar/date/time	VARCHAR	Stored as a string.
bigint	INT64
integer	INT32
smallint	INT16
double precision	DOUBLE
real	FLOAT
boolean	BOOL
array	ARRAY
json	JSON

PostgreSQL table names are transferred to Zilliz Cloud with the following considerations:

Scenario	Impact	Solution
Default naming	Collection names match source table names exactly	Names are preserved as-is from PostgreSQL
Naming conflicts	Cannot submit job if a collection with the same name already exists	Delete existing collection, choose a different database, or rename during migration configuration
Collection name modification	Supported during migration	You can rename collections during the migration configuration process

The following features are not supported for PostgreSQL migration:

Limitation	Impact	Alternative
Dynamic to fixed field conversion	Cannot convert existing dynamic fields to fixed types	Fields maintain their original dynamic nature
Add more fields	Cannot add new fields during migration	Only existing Elasticsearch fields are migrated