Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[ORM] ORM always destroy my manual set indexes. (e.g. when using `pgvector`)

Open
  • Is something wrong?
#2,731 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
38/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Quiet
Tech stack
postgresql, typescript
Domain
databases

Research direction

Reproduce with bun zen migrate dev --create-only after adding an Unsupported("vector(384)") field to schema.zmodel, then add manual HNSW indexes on chunks and rerun bun zen migrate dev. The payload names no source files; the work is in the migration diffing engine that compares the Prisma schema against the live PostgreSQL database and emits DROP statements, so start by locating where migrations are generated and how Unsupported fields are handled. Done means a follow-up migration leaves manually created indexes intact.

Written by the indexing model from the issue text.

Description

Description and expected behavior
When using PostgreSQL extensions like pgvector and manually creating indexes in migrations the ORM will automatically roll back these manual changes and want to DROP these indexes.

How to reproduce?

  1. Add a "Unsupported" field to the schema.zmodel
  2. Create a index using `bun zen migrate dev --create-only"
  3. Add indexes manually in this migrations
  4. Run bun zen migrate dev to apply -> In this case the CLI automatically creates another migration which always DROPs these manual indexes (running bun zen migrate deploy mitigates this one time, but after another migrations it automatically drops all manual indexes again)

Environment (please complete the following information):

  • ZenStack version: 3.8.0
  • Database type: PostgreSQL
  • Node.js/Bun version: Bun v1.3.14
  • Package manager: Bun

Sample schema

type Vectors {
    dimensions Int?

    vec384     Unsupported("vector(384)")?
    vec768     Unsupported("vector(768)")?
    vec1024    Unsupported("vector(1024)")?
    vec1536    Unsupported("vector(1536)")?
    vec3072    Unsupported("halfvec(3072)")?
}

model Chunk with Vectors {
  id String @id @default(uuid())
}

Manual indexes in sql

-- ============================================================
-- CHUNKS
-- ============================================================

CREATE INDEX IF NOT EXISTS idx_chunks_vec384
  ON chunks USING HNSW ("vec384" vector_cosine_ops)
  WITH (m = 16, ef_construction = 64);

CREATE INDEX IF NOT EXISTS idx_chunks_vec768
  ON chunks USING HNSW ("vec768" vector_cosine_ops)
  WITH (m = 16, ef_construction = 64);

CREATE INDEX IF NOT EXISTS idx_chunks_vec1024
  ON chunks USING HNSW ("vec1024" vector_cosine_ops)
  WITH (m = 16, ef_construction = 64);

CREATE INDEX IF NOT EXISTS idx_chunks_vec1536
  ON chunks USING HNSW ("vec1536" vector_cosine_ops)
  WITH (m = 16, ef_construction = 64);

-- halfvec braucht halfvec_cosine_ops
CREATE INDEX IF NOT EXISTS idx_chunks_vec3072
  ON chunks USING HNSW ("vec3072" halfvec_cosine_ops)
  WITH (m = 16, ef_construction = 64);
Dominant language
TypeScript
Stars
2.9k
Forks
157
Avg merge
11h 42m
Merged PRs (30d)
20

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from zenstackhq/zenstack

All issues in zenstackhq/zenstack

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.