Skip to main content

Configuration

384d sentence-transformersFree open source software

Ideal for text embeddings - measures angle between vectors, invariant to magnitude.

Split by a fixed number of tokens with configurable overlap. Simple and predictable.

Total documents:10,000

Storage estimate20 MB
Monthly cost$0 (self-hosted)
Sizes384d
Warnings 0
-- Redis Stack HNSW Vector Index
-- Run via redis-cli or ioredis

FT.CREATE idx:docs
  ON HASH PREFIX 1 doc:
  SCHEMA
    id          TAG
    content     TEXT
    source      TAG
    created_at  NUMERIC
    embedding   VECTOR HNSW 6
      TYPE FLOAT32
      DIM 384
      DISTANCE_METRIC COSINE
      M 16
      EF_CONSTRUCTION 200

-- Optional: store JSON documents
FT.CREATE idx:docs:json
  ON JSON PREFIX 1 doc:
  SCHEMA
    $.id          AS id          TAG
    $.content     AS content     TEXT
    $.source      AS source      TAG
    $.created_at  AS created_at  NUMERIC
    $.embedding[*] AS embedding  VECTOR HNSW 6
      TYPE FLOAT32
      DIM 384
      DISTANCE_METRIC COSINE
      M 16
      EF_CONSTRUCTION 200

How it works

Choose the template

Select the embedder type from over a dozen options (Sentence Transformers, Open AI, Cohere, etc.). The size is automatically populated.

Configure the database.

Choose the target vector database, distance metric and chunking strategy. The HNSW parameters are suggested automatically.

Get the Schema

The tool generates executable SQL scripts and estimates of Hetzner's cost and storage usage in a single copy with one-click deployment to your project.

Why use this tool?

One-click cross-db integration

Supported databases for Vector Database, ready-to-use SQL scripts to deploy immediately: change the db and regenerate in one second.

Hetzner cost aware

Estimate of storage and monthly cost based on Hetzner's VPS CCX13 / CCX23. Highlight warnings for Pinecone Cloud and paid models.

Rationalized HNSW parameters

Every parameter (M, ef_construction, ef) is generated with an explicit rational. No anonymous "magic numbers".

Come utilizzare Vector DB Schema Designer

Choose an embedding model

Choose one of the 12+ available models (sentence-transformers, OpenAI, Cohere, Voyage): vector size and token cost are automatically compiled.

Configure DB, metrics, and chunking

Choose the target vector database (Redis Stack, Qdrant, Weaviate, Pinecone, pgvector, Milvus), distance metric, and chunking strategy with relative size and overlap.

Set number of expected documents

Indicate how many documents you expect to index: the tool uses this value to estimate storage and monthly cost of the solution.

Generate and copy the template

Pass through DDL/Script, JSON Config and Index Params to see output in desired format, then copy with a single click into your project.

Suggerimenti

  • If you don't know yet which DB user to use, generate the schema for Redis Stack HNSW or pgvector first: these are self-hosted options with zero cost and are more common in existing stacks.
  • Try changing the chunking strategy on the same model to compare the impact on estimated storage before finalizing the configuration.
  • Check the tab "Index Params" every time you change the number of documents expected: recommended HNSW parameters adapt to the scale of the dataset.

Domande frequenti

Which vector database should I choose for an RAG project?

Depends on the context: Redis Stack HNSW and pgvector are great for those already using Redis or Postgres in production and avoid self-hosted infrastructure with zero cost. Qdrant and Weaviate offer more advanced feature vector-native features. Pinecone is a cloud-managed paid service, convenient but with recurring costs that the tool warns about.

How do I choose the chunk size and overlap?

Chunk sizes of 256-512 tokens improve retrieval precision but increase the number of vectors to index; larger chunks (1024+) maintain more context but may dilute semantic relevance. A 10-20% overlap between chunk sizes avoids losing information at the boundaries between chunks.

What distance metric should I use?

Cosine similarity is the default choice for most embedding models (measures direction, not magnitude). Dot product is preferred when the model is already normalized and computation is to be saved. Euclidean (L2) is useful when vector magnitude carries relevant information. The tool shows the specific reason for the selected metric.

What is this estimate of storage and monthly cost based on?

Storage cost is calculated by multiplying the number of expected documents by the vector embedding size (in float32), plus HNSW index overhead. Monthly costs are based on Hetzner CCX13/CCX23 VPS for self-hosted solutions (often €0 extra if infrastructure is already present) or public pricing for cloud services like Pinecone.

Are generated HNSW parameters (M, ef_construction, ef) valid for production?

Values are reasonable starting points based on standard heuristics for the dataset size indicated, each accompanied by a rationale in the "Index Params" tab. For very large datasets or strict latency requirements, they should be validated with specific benchmarks on your real load before deployment to production.