Vectors in SQL Server 2025 and Oracle 23ai: What Transfers

Tier: Core · Workflow area: Vector & AI Features · ~35 minutes

Multi-engine estates are the DBA's reality: the skills premium goes to the person who can say "same concept, different knob" across all of them. Vector search landed natively in SQL Server 2025 (VECTOR type, DiskANN-based indexing, external model integration) and Oracle 23ai (AI Vector Search, in-database ONNX models). This playbook uses AI as a translation partner — with every claim verified against the engine's own documentation and a live test, because vector features are new enough that models confidently describe preview builds that changed before GA.

When to use

• Your estate runs more than one enginethe pgvector feature you shipped is now wanted on the SQL Server side, or an Oracle-based ERP wants semantic search on its own data.
• Platform selection with vendors in the roomyou need to evaluate vector claims across engines in a week, with enough hands-on depth to separate capability from slideware.
• Interview and role prep"vector search across engines" is a differentiating screen question for senior DBA roles; the transfer map is the honest way to earn it.

When NOT to use

• As a reason to migrate engines"Postgres has pgvector" is not a migration case, and neither is any single feature. Every engine here does credible vector search; use the one holding the data.
• On unverified version assumptionsthese features are version-gated (SQL Server 2025+, Oracle 23ai+) and cloud editions lag or lead on-prem. Confirm your exact build before designing anything.
• When the workload never leaves one enginedepth beats breadth; go run pb-28 through pb-31 on your actual platform instead.

The recipe

1. 1.

   Build the transfer map with AI — then treat every row as unverified. Prompt for the concept-to-concept translation:

   Copy

   I know pgvector well: vector(n) columns, <=> cosine operator, HNSW
   with m/ef_construction/ef_search, CREATE INDEX CONCURRENTLY,
   maintenance_work_mem for builds. Build me a three-column transfer
   table to SQL Server 2025 and Oracle 23ai covering: column type and
   dimension declaration, distance functions, ANN index type and its
   tuning knobs, exact-vs-approximate query syntax, embedding
   generation options, and index maintenance behavior. Mark any row
   you are not certain survived to GA with [VERIFY].
   

   The [VERIFY] instruction matters: these features evolved through previews, and the model's training data may straddle the changes.

2. 2.

   Verify the SQL Server column on a free Developer Edition. Spin up SQL Server 2025 Developer in a container and prove the basics:

   Copy

   CREATE TABLE products_v (
     id int PRIMARY KEY,
     embedding VECTOR(768) NOT NULL
   );
   
   SELECT TOP 10 id,
          VECTOR_DISTANCE('cosine', embedding, @query_vec) AS dist
   FROM products_v
   ORDER BY dist;
   

   Then the ANN path: CREATE VECTOR INDEX (DiskANN-based) and the VECTOR_SEARCH function for approximate query — check which of exact and approximate your query actually used, the same plan-reading habit as always. Note the ops difference from pgvector: DiskANN is disk-resident by design, so the memory conversation shifts from "graph in RAM" to I/O behavior, and index DDL options control build resources.

3. 3.

   Verify the Oracle column on 23ai Free. Same drill in a 23ai Free container:

   Copy

   CREATE TABLE products_v (
     id NUMBER PRIMARY KEY,
     embedding VECTOR(768, FLOAT32)
   );
   
   SELECT id FROM products_v
   ORDER BY VECTOR_DISTANCE(embedding, :query_vec, COSINE)
   FETCH APPROX FIRST 10 ROWS ONLY;
   

   Oracle's distinctive moves to test: in-memory neighbor graph (HNSW-style) vs. neighbor-partition (IVF-style) index choices, the TARGET ACCURACY clause that lets a query request a recall level, and in-database ONNX embedding models via DBMS_VECTOR — which removes the external embedding endpoint from the architecture entirely. The HNSW-style index living in memory makes RAM sizing a first-class ops question again, opposite of DiskANN's trade.

4. 4.

   Port one real feature end-to-end, not just syntax. Take pb-29's semantic search (schema, backfill, index, hybrid query) and rebuild it on one target engine. The porting friction you hit — how embeddings get generated, how filters interact with ANN, what the plan shows — is the real lesson; write each one down as you hit it.

5. 5.

   Rerun the pb-31 measurement on the new engine. Ground truth via exact scan, the same 100 queries, recall@10 and p95 latency. Engines differ most exactly where marketing is loudest; your numbers on your data are the only cross-engine comparison worth repeating in a meeting.

6. 6.

   Publish the estate note. One page: the verified transfer table, per-engine gotchas you hit, version and edition gates, and your measured numbers. This is the document that makes you the vector-search owner across the estate rather than the pgvector person.

Make it yours

• MongoDB AtlasAtlas Vector Search with $vectorSearch aggregation and built-in hybrid search; the concept map holds, the query language does not. Same drill: transfer table, live verify, measure.
• MySQL 9 / HeatWavevector type and distance functions exist; check index support carefully — this is the engine where the gap between "has vectors" and "has production ANN" is widest. Verify on your version.
• Cloud-managed flavorsAzure SQL, RDS Oracle and their kin gate these features by service tier and rollout wave. The verification step is not optional there; the docs page and your instance can disagree.

Quality check

• Every transfer-table row was verified on a live instancethe table started as AI output and ended as tested fact. Rows you could not test are still marked [VERIFY] in the published note.
• Version and edition gates are recorded per engine"works in 23ai Free" and "available on our licensed estate" are separate claims; both are in the note with specifics.
• The measurement was rerun, not extrapolatedrecall and latency numbers from Postgres were not assumed to transfer. Each engine got its own pb-31 pass, however abbreviated.
• Ops behaviors were tested, not read aboutindex build resource use, replica/standby behavior of the vector index, and backup size impact were each observed once on the target engine.