DiscovAI Search: The Open Source AI Search Engine That Actually Understands Your Data

Topics:
AI Search Engine
Open Source RAG
pgvector
Supabase
Next.js
LLM Search

There is a particular kind of frustration that developers know well: you have a well-structured knowledge base, a solid documentation site, or a curated directory of AI tools — and your search is still returning results that make you question the meaning of relevance. Keyword matching looks for the words you typed, not for what you meant. That gap between intent and result is exactly where DiscovAI Search was built to live.

DiscovAI is an open source AI search engine designed for developers who need intelligent, context-aware retrieval over their own data — whether that’s technical documentation, an AI tools directory, or any custom dataset. It is not a SaaS product with a pricing page hiding the good stuff behind a paywall. It is a composable, self-hostable system built on a stack that most modern developers already know: Next.js, Supabase, pgvector, OpenAI embeddings, and Redis for caching. The architecture is intentional, the code is readable, and the concept behind it is worth understanding even if you never deploy it yourself.

This article walks through what DiscovAI actually does, how its RAG-based search pipeline works under the hood, why the technology choices matter, and what you should take away if you are evaluating open source semantic search tools for a real project.

What Is DiscovAI and Why Does It Exist

The DiscovAI search project emerged from a real and recurring developer problem: the AI tools discovery platform space has exploded with hundreds of new tools every month, but finding the right one is still mostly a matter of luck, Twitter threads, and someone’s curated newsletter. Search on most directories is embarrassingly primitive — type „image generation API with rate limiting“, get results for tools that happen to contain the word „image“ somewhere in their description. Not ideal.

DiscovAI was built to solve this with a proper semantic search engine that understands queries at the meaning level, not the character level. Instead of matching tokens, it converts both the query and the indexed content into high-dimensional vector embeddings using OpenAI’s embedding API. The distance between those vectors in embedding space represents semantic similarity — and that is what drives the ranking. The practical result is that a query like „tool that converts speech to structured text“ correctly surfaces transcription APIs even if none of them used those exact words in their descriptions.

Beyond being a useful product, DiscovAI is a reference implementation. It demonstrates how to wire together a RAG search system — Retrieval-Augmented Generation — in a way that is production-viable, open source, and not buried inside a proprietary cloud. For developers building their own AI documentation search, internal knowledge bases, or custom data search AI systems, it is a blueprint worth studying carefully.

The Architecture: How an LLM-Powered Search Actually Works

At its core, LLM-powered search is a two-stage process. First, retrieve the most relevant content from a corpus. Second, use a language model to synthesize a useful response from that content. The first stage is the hard part, and it is where most implementations either get it right or fall apart entirely. DiscovAI gets it right by using a vector search engine as the retrieval backbone — specifically, pgvector running inside Supabase.

When data is indexed into DiscovAI, each piece of content — a tool description, a documentation snippet, a knowledge base entry — is converted into a vector embedding via the OpenAI Embeddings API (text-embedding-ada-002 or its successors). These vectors are stored in a Postgres table with a vector column, managed by the pgvector extension. At query time, the user’s input is embedded using the same model, and a nearest-neighbor search is run against the stored vectors using cosine similarity. The pgvector index makes this fast enough to be practical at real scale without requiring a dedicated vector database service.

The retrieved documents are then passed as context to an LLM — currently OpenAI’s chat completion API — which generates a coherent, grounded response. This is the RAG loop: retrieve, augment, generate. The key advantage over raw LLM querying is that the model is working with actual content from your dataset, not from its training data. Hallucinations are constrained. Answers are traceable. That matters enormously for AI knowledge base search and documentation use cases where accuracy is non-negotiable.

Supabase and pgvector: The Database Layer That Makes It Possible

The decision to build DiscovAI on Supabase vector search with pgvector is one of the more interesting architectural choices in the project. There are dedicated vector databases — Pinecone, Weaviate, Qdrant, Chroma — and they are all excellent at what they do. But they add operational complexity and cost, and they separate your vector data from the rest of your relational data. If you already have a Postgres-based application, reaching for pgvector is often the smarter call.

pgvector is a Postgres extension that adds a native vector data type and operators for similarity search. With it, you can store embeddings alongside regular relational columns, join vector similarity results with standard SQL filters, and manage everything through a single database connection. Supabase ships pgvector out of the box and provides a clean JavaScript SDK for interacting with it, which is exactly why it fits naturally into a Next.js AI search application. The schema for a vector search table looks approximately like this:

create table documents (
  id bigserial primary key,
  content text,
  metadata jsonb,
  embedding vector(1536)
);

create index on documents
  using ivfflat (embedding vector_cosine_ops)
  with (lists = 100);

The ivfflat index provides approximate nearest-neighbor search, which trades a small amount of recall for a significant speed improvement at scale. For most knowledge base or documentation search use cases, the tradeoff is entirely acceptable. Supabase also exposes this through an RPC function that you can call from the client or server side with a single line, keeping the application layer clean and the latency low.

Redis Caching: Because Embedding Every Query Twice Is Expensive

Calling the OpenAI Embeddings API for every single search query adds latency and cost. In a low-traffic internal tool, this is tolerable. In a public-facing AI search API or an AI tools discovery platform with real user load, it becomes a problem fast. DiscovAI addresses this with a Redis search caching layer that stores embedding vectors for recently-seen queries and returns cached results without hitting the API again.

The caching strategy is straightforward: hash the incoming query string, check Redis for a cached embedding vector and result set, return the cached response if found, otherwise generate the embedding, run the vector search, cache the output with a TTL, and return the result. This pattern reduces API costs dramatically for any dataset where users tend to ask similar questions — which is basically every real-world deployment. Documentation sites, AI tool directories, and internal knowledge bases all have predictable query distributions.

Beyond simple result caching, Redis can also serve as a rate-limiting layer and a session store, which means the infrastructure investment pays dividends across the application. If you are building a developer AI search platform that needs to scale gracefully, Redis is not optional — it is the difference between a demo and a product. DiscovAI treats it as a first-class citizen of the stack rather than an afterthought bolted on when things get slow.

The Next.js Frontend: Where the LLM Search Interface Lives

The frontend of DiscovAI is built with Next.js, and the choice matters more than it might seem. Next.js App Router with Server Components and Route Handlers allows the search pipeline to run server-side, keeping API keys out of the browser, enabling streaming responses, and making it trivial to deploy on Vercel or any Node-compatible host. The LLM search interface benefits from server-side rendering because the first meaningful paint can include actual search results rather than a loading spinner followed by a client-side data fetch.

The search UI is intentionally minimal. A text input, a results panel, and a generated summary at the top. This is correct design for an AI powered knowledge search interface — the goal is to answer the user’s question, not to impress them with animated gradients. The streaming capability means the LLM-generated summary appears token by token, which feels responsive even when the underlying model takes three seconds to generate a full paragraph. Streaming is implemented via the Vercel AI SDK, which provides hooks like useChat and useCompletion that handle streaming state elegantly in React.

For developers who want to embed DiscovAI’s capabilities into an existing application, the project exposes a clean AI search API via Next.js Route Handlers. POST a query, receive a JSON response with ranked results and an optional LLM-generated summary. The API design is RESTful and stateless, which means it can be integrated into any frontend framework, used from a mobile app, or called from a backend service without modification.

Custom Data Indexing: Making the Search Engine Yours

One of the most practically valuable aspects of DiscovAI is its approach to custom data search AI. The system is not opinionated about what you index. You can feed it documentation pages, product descriptions, support tickets, code comments, research papers, or the collected wisdom of your internal wiki. The ingestion pipeline — fetch content, chunk it into appropriately-sized segments, generate embeddings, store in pgvector — is exposed as a set of utility functions that you can call from a script, a cron job, or an admin interface.

Chunking strategy is worth dwelling on because it has a significant impact on retrieval quality. Chunk too large, and the embedding averages across too much content, losing specificity. Chunk too small, and individual chunks lack enough context for the LLM to generate useful answers. DiscovAI uses a sliding window approach with overlapping chunks, which ensures that concepts that span paragraph boundaries are represented in at least one chunk without duplication of entire sections. For AI documentation search specifically, this matters because technical content often has dense dependencies between consecutive paragraphs.

The metadata stored alongside each embedding is equally important. Source URL, document title, section heading, timestamp, content type — all of this can be used to filter vector search results before or after retrieval. Filtering by metadata in pgvector is done with standard SQL WHERE clauses applied on the jsonb metadata column, which means you can scope searches to specific sections, time ranges, or content categories without sacrificing the semantic power of the vector similarity scoring.

Open Source RAG Search: What Sets DiscovAI Apart From the Alternatives

The open source RAG search ecosystem is genuinely rich at this point. LlamaIndex, LangChain, Haystack, DSPy, and a dozen others provide frameworks for building retrieval pipelines. Weaviate, Qdrant, and Chroma are purpose-built vector databases with excellent documentation. Meilisearch and Typesense offer hybrid search with vector capabilities. So where does DiscovAI fit, and why would you choose it over any of these?

The answer is specificity. DiscovAI is not a framework — it is a complete, deployable application with a specific purpose: making an AI tools directory and documentation corpus searchable with semantic intelligence. If your use case aligns with that — building a developer ai search platform, an ai tools discovery platform, or an intelligent front-end for your documentation — DiscovAI gives you a working system instead of a collection of primitives. You do not need to figure out how to wire pgvector to Next.js while also implementing a Redis caching strategy and a streaming LLM interface. Someone already did that. The code is on GitHub. Fork it.

The tradeoff is that DiscovAI is opinionated. It uses Supabase specifically, not an arbitrary Postgres instance. It uses OpenAI for embeddings and completion, not a local model. It assumes Next.js on the frontend. If those constraints fit your stack, the time savings are substantial. If they do not, you will be refactoring from the start — at which point the more composable frameworks become the better choice. That is not a criticism; it is an honest characterization of what the project is for.

Deploying DiscovAI: What You Actually Need to Get Started

The prerequisites for running DiscovAI are refreshingly lean. You need a Supabase project with pgvector enabled (which it is by default on all Supabase tiers), an OpenAI API key, a Redis instance (Upstash works well for serverless deployments), and a Next.js hosting environment. Vercel covers the last point with zero configuration. The total cost for a low-traffic deployment is well under $10/month, with the OpenAI API being the primary variable cost depending on query volume and content corpus size.

Environment variable setup is the main operational step. The project uses a .env.local file with clearly named variables for the Supabase URL and anon key, the OpenAI API key, and the Redis connection string. Database schema setup is handled by SQL migration files included in the repository. Run the migrations against your Supabase project, set the environment variables, deploy to Vercel with a single CLI command, and you have a live ai search api endpoint and a functional search interface within the hour. That is genuinely fast for something this capable.

For production deployments, a few additional considerations apply. The pgvector IVFFlat index should be tuned — specifically, the lists parameter should be set to approximately sqrt(rows) for optimal recall-speed tradeoff. OpenAI API calls should be wrapped with retry logic and timeout handling. The Redis TTL for cached results should reflect your content update frequency — a documentation site that updates weekly can cache aggressively, while a live AI tools directory might need shorter TTLs or cache invalidation hooks tied to content updates. None of this is complicated, but it separates a demo from a system you can trust.

The Broader Significance: AI Search as Developer Infrastructure

Projects like DiscovAI matter beyond their immediate utility because they normalize a new tier of developer infrastructure. Two years ago, adding semantic search to an application required either a managed service contract or significant machine learning expertise. Today, a developer who knows Next.js and has used Supabase before can ship a production-grade ai semantic search tools implementation in an afternoon. That compression of complexity is not trivial — it changes what is buildable by a solo developer or a small team.

The vector search engine concept, once the domain of specialized search teams at large companies, is now a pgvector extension and an API call away. The llm search interface that would have required a custom model fine-tuning pipeline is now a system prompt and a streaming response handler. The ai developer tools search problem — finding the right tool in an overwhelming ecosystem — is now a solved problem for anyone willing to clone a repository and configure three environment variables.

What remains genuinely hard is not the technology but the craft: writing good chunking strategies, designing retrieval pipelines that handle edge cases gracefully, building interfaces that communicate uncertainty to users rather than presenting hallucinated confidence as fact. DiscovAI gets the infrastructure right and leaves room for that craft layer. That is exactly the right division of responsibility between a reference implementation and the applications built on top of it.