In our tests on 100,000 rows, zeroing out the vectors and vacuuming before dropping the column reclaimed 381 MB of TOAST space for reuse by subsequent model upgrades.
Transactional mode considerations for auto embeddings
If your application uses auto embeddings with incremental_refresh_mode => ‘transactional’, vectors are generated synchronously inside each write transaction. Upgrading in transactional mode follows the same sequence shown above, with three key differences:
-
Step 3 is skipped: You don’t need to run ai.refresh_embeddings(), because new writes update both columns automatically.
-
Column swap technique is not supported: You must use the GUC + SRF abstraction method, which does not impact the triggers managed by auto embeddings.
-
Write latency increases during migration: While both models are configured, each row write executes two remote embedding calls.
Because gemini-embedding-001 generates a more expressive 3072-dimensional embedding, its remote inference call takes longer. In our tests, we observed the following latency profiles for single-row UPDATE operations with transactional mode enabled for auto embeddings:
|
Migration Phase |
Active Models |
Median Single-Row Write Latency |
|---|---|---|
|
Baseline |
text-embedding-005 |
~37.5 ms |
|
Active Migration |
Both Models Active |
~191.0 ms |
|
Post-Cutover |
gemini-embedding-001 |
~172.0 ms |
Be sure to review your application’s write latency budget before choosing transactional mode for auto embeddings, especially with higher-dimension models.
Disk space and memory resource planning
Because old and new vector columns coexist during migration, your table storage will grow based on peak usage. Based on our testing, we observed the following average storage per row for each embedding type:
|
Embedding Model |
Output Dimensions |
Estimated Storage Per Row |
|---|---|---|
|
text-embedding-005 |
768 |
~4.5 KB / row |
|
gemini-embedding-001 |
3072 |
~13.3 KB / row |
Based on these estimates, you can use the formula below to estimate your storage space:
-
New vector column: Total Rows × ~13.3 KB (approx. 3x legacy storage).
-
New ScaNN index: Total Rows × ~0.6 KB.
-
Headroom Allocation: Add ~25% overhead for WAL generation and page updates during backfill and vacuum operations.
Example: A table with 10 million rows requires approximately 133 GB of disk space for the new vector column, 6 GB for the ScaNN index, plus headroom.
AlloyDB combines native PostgreSQL primitives with built-in AI capabilities to make upgrading vector embedding models in production faster and earlier, with no maintenance downtime or complex application-side changes. By combining AlloyDB AI auto embeddings and Model Endpoint Management with standard PostgreSQL operational controls, database administrators and developers can keep their semantic search models up to date with the latest embedding model capabilities as soon as they are released.
To get started, launch an AlloyDB trial cluster and consult the official AlloyDB AI documentation.
