Embeddings transform text, images, and other data into numerical vectors, allowing AI to understand relationships. While powerful for semantic search and RAG, for many initial AI features in India, simpler solutions like PostgreSQL's `pgvector` or Full-Text Search often offer better cost-effectiveness and faster deployment than dedicated vector databases.
A practical, jargon-free guide for Indian engineering teams and founders — part of the Learn AI with Reeturaj series on InBharat AI.
At their core, embeddings convert diverse data types—like text, images, audio, or even graphs—into dense, low-dimensional numerical vectors [1, 2, 3, 4]. Think of it like this: if you have a word, a sentence, or even a whole document, an embedding model turns that complex human-readable information into a list of numbers. These numbers capture the semantic meaning and context of the original data.
Imagine a 300-dimensional space. Each word or phrase isn't just a point in that space, but its position relative to other words tells you how similar or related they are. Words with similar meanings, like "doctor" and "physician," will have vectors that point in roughly the same direction and are close to each other. Words with opposite meanings, like "hot" and "cold," will be far apart.
Once your text is turned into these vectors, you can do powerful things with them. The most common operation is calculating cosine similarity. This metric tells you how similar two vectors are by measuring the cosine of the angle between them. A cosine similarity of 1 means the vectors are identical (same meaning), 0 means they are orthogonal (no relation), and -1 means they are diametrically opposite (opposite meaning).
This is why embeddings are so crucial for tasks like semantic search. Instead of just matching keywords, you can find documents that are conceptually similar to your query, even if they don't share exact words. For example, searching "how to fix a leaky tap" could return results about "plumbing repairs" or "faucet maintenance" because their embeddings are semantically close.
Embeddings are a cornerstone of modern AI applications, especially for Retrieval Augmented Generation (RAG) systems, which we use extensively at InBharat for products like TestsPrep to provide relevant study material. (If you're building an LLM-powered product, I highly recommend reading my article on RAG: How Indian AI Teams Make LLMs Actually Useful).
They are excellent for:
However, for many common use cases, especially when you're just starting to integrate AI features into an existing Indian product, the overhead of a dedicated vector database might be overkill. This is where pgvector and Full-Text Search come into play.
When we build for Bharat, we always consider cost, latency on varied network conditions (from 4G in Tier-2 cities to fiber in metros), and the existing tech stack of SMBs. Adding a new, specialized database like Pinecone or Weaviate for vector search introduces:
pgvectorPostgreSQL is the workhorse database for countless Indian startups. It's robust, reliable, and most teams already know how to manage it. The pgvector extension changes the game by allowing you to store and query embeddings directly within your existing PostgreSQL database.
Here's why pgvector is often a smarter choice for your first AI feature:
pgvector is negligible, often just increased storage and CPU usage.Let's say you have a table documents with id, content, and embedding (a vector type column). A simple similarity search looks like this:
SELECT id, content, 1 - (embedding <=> '[query_embedding]') AS similarity
FROM documents
ORDER BY similarity DESC
LIMIT 5;
The embedding <=> '[query_embedding]' is the L2 distance operator. pgvector supports various distance metrics and indexing (like HNSW) for performance. For a detailed guide on pgvector, I recommend checking out the official documentation or a good tutorial.
Before you even consider embeddings, ask yourself: Does my problem truly require semantic understanding, or can keyword matching suffice?
PostgreSQL's built-in Full-Text Search is incredibly powerful for many use cases. If your users are searching for specific keywords, phrases, or combinations of terms, FTS can deliver fast, relevant results with minimal setup. For example, if you're building an internal document search where users know exactly what terms they're looking for, FTS is often more than adequate.
Consider a scenario where a user on Sahayaak Seva is looking for a specific medical guideline document by its title or known keywords. FTS will be faster and simpler to implement than an embedding-based solution. It's about matching intent.
pgvector vs. Dedicated Vector Stores| Feature | pgvector (PostgreSQL) |
Dedicated Vector Store (e.g., Pinecone, Weaviate) |
|---|---|---|
| Setup/Ops Cost | Low (leverages existing Postgres) | High (new infrastructure, learning curve, separate billing) |
| Data Sync | Automatic (same database) | Manual/ETL needed, potential for data staleness |
| Scalability | Scales with Postgres; good for moderate datasets (millions) | Designed for massive scale (billions of vectors) |
| Query Latency | Very good for medium scale; depends on Postgres tuning | Optimized for low-latency similarity search at extreme scale |
| Feature Set | Basic vector operations, HNSW indexing | Advanced filtering, hybrid search, multi-modal embeddings, RAG-specific features |
| Familiarity | High (SQL, Postgres ecosystem) | Low (new APIs, concepts, tools) |
For most Indian SMBs building their first AI features, pgvector offers a compelling balance of power and practicality. It allows you to experiment with semantic search, build your RAG pipeline, and get your AI features to market faster without committing to a complex and expensive new piece of infrastructure. Only when you hit the scaling limits of pgvector (e.g., tens of millions of vectors with very high query throughput) should you consider migrating to a dedicated vector database.
At InBharat, we often start with pgvector for our initial AI features. For instance, when building the first version of our AI-powered study assistant for TestsPrep, we used pgvector to store embeddings of study materials. This allowed us to iterate quickly, test different embedding models, and gather user feedback without incurring significant infrastructure costs. We could easily integrate it with our existing data pipelines and deploy it with confidence. Only when a feature shows significant traction and requires scaling beyond what pgvector can comfortably handle do we consider more specialized solutions.
This pragmatic approach ensures we're building with the Indian context in mind: optimizing for cost, leveraging existing skills, and delivering value quickly. It's about smart engineering, not just chasing the latest shiny tech.
Embeddings are fundamental to modern AI, transforming complex data into a numerical format that allows for powerful semantic understanding. However, for many Indian product teams, especially when starting out, integrating pgvector into your existing PostgreSQL setup or even relying on robust Full-Text Search can provide significant AI capabilities without the added cost and complexity of a dedicated vector database. Choose the simplest solution that solves your problem effectively, and scale up only when your needs genuinely demand it. To learn more about how we build AI products for India, explore other articles on the InBharat.ai content hub, like Desh Ka AI: What It Means to Build for Bharat.
pgvector suitable for all AI applications?pgvector is excellent for many initial AI features, especially semantic search and RAG, within moderate datasets (up to tens of millions of vectors). For extremely large-scale applications with billions of vectors or very high query throughput, dedicated vector databases might offer better performance and advanced features.
pgvector compare to cloud-managed vector services?pgvector offers simplicity and cost-effectiveness by leveraging your existing PostgreSQL instance. Cloud services often provide managed scalability, advanced features, and potentially lower latency at extreme scale, but come with higher operational overhead and cost. The choice depends on your project's specific requirements and budget.
Absolutely. Many robust search systems combine keyword-based Full-Text Search with semantic search using embeddings. This hybrid approach allows you to capture both explicit keyword matches and conceptual relevance, providing a more comprehensive search experience for users.