Sourcegraph vs GitHub Code Search vs Rolling Your Own: A Build-vs-Buy Cost Table

If all your code is on GitHub and you mostly need "where is this string or symbol", GitHub code search is free and good enough. Buy Sourcegraph when you need every branch, every code host, precise cross-repo navigation and batch changes, and can sign a $16K-plus contract. Build your own only when search is product infrastructure you will staff.

What GitHub code search can and can't do

GitHub's code search does more than its reputation suggests. It supports regular expressions (wrap the pattern in slashes), boolean operators, and qualifiers like repo:, org:, path:, language: and symbol:. Private repositories are searchable by anyone who can already read them, and it costs nothing beyond your GitHub plan.

Its limits are documented and specific:

• It searches the default branch only, so code on a feature branch or a release branch is invisible.
• It returns at most 100 results for any search, across 5 pages. For a question like "find every caller of this deprecated helper across 300 repos", that cap is the main problem.
• Files over 350 KiB, vendored code, generated code and binary files are skipped, and very large repositories may not be indexed at all.
• Regex has no look-around, and repo: and org: need the full name, with no partial matches.
• symbol: finds definitions, not references, and only in about 20 languages.
• You must be signed in, even for public code.
• The REST API for code search is limited to 10 requests a minute and searches the default branch only, so building tooling on top of it hits a wall quickly.

GitHub Enterprise Server documents its own code search with different limits: default branch only, up to 4,000 private and internal repositories, no archived repos.

For a team on github.com searching current code, GitHub code search covers most daily lookups. It breaks down on history, branches, other code hosts, and any question with more than 100 answers.

Is Sourcegraph just a glorified GitHub search?

People do say this, and it is half right. If you only ever type a string into a box and read the top 20 hits, Sourcegraph and GitHub feel similar.

The difference shows up at scale, where Sourcegraph searches every branch and every code host, matches across lines, searches commit diffs and messages, and has compiler-accurate code navigation (go to definition and find references across repositories) for the languages it has indexers for. Batch Changes lets one person open the same change across hundreds of repos. Code Insights tracks a pattern over time, like how many files still import a deprecated package. Deep Search adds AI-written answers, and an MCP server gives coding agents the same search (MCP, the Model Context Protocol, is the standard way an AI agent calls an outside tool).

The buying side has changed. Sourcegraph's pricing page lists one plan today: Enterprise, starting at $16K, as a minimum annual contract that includes credits for AI features, with single-tenant cloud or self-hosted deployment. The main Sourcegraph code moved private in 2024; the public repository is an archived snapshot. Zoekt, the trigram search engine Sourcegraph uses (it indexes every three-character sequence), is still open source under Apache-2.0 and actively maintained.

For a 300-engineer org with five code hosts, $16K a year is small. For a 10-person team, the same $16K is the reason they are reading this post. If you want the list of other options, our Sourcegraph alternatives guide covers them by job.

What rolling your own actually involves

Putting zoekt behind a web interface is the usual starting point, and it is a reasonable one. "Our own search stack" can mean two very different builds: lexical search, which matches the exact text you type, and semantic search, which matches what you mean.

Build 1: lexical search with zoekt (or ripgrep)

For one repo on one laptop, ripgrep (a command-line text search tool) needs no index and is fast enough. The trouble starts when you want shared search across hundreds of repos, which needs these parts:

1. A sync job that clones and fetches every repo, on a schedule or from webhooks.
2. The zoekt indexer, run per repo, with shards on disk.
3. The zoekt web server or its JSON and gRPC API.
4. Permissions, which is the part teams underestimate. If a private repo shows up in search for someone who can't read it on GitHub, the search tool is leaking code, and mapping GitHub team permissions onto search results is real work.
5. Monitoring, disk growth, and upgrades.

Sourcebot is the middle path here: it ships zoekt inside a single Docker image with a UI, multi-host sync, every branch, and a free tier. Permission syncing and SSO are on its paid Pro plan.

Build 2: semantic search with embeddings

The semantic build lets people ask questions in plain English. The pipeline is to parse files with tree-sitter (a parser library) so you can cut them at function and class boundaries, embed each chunk (turn it into a list of numbers that captures its meaning), store vectors in pgvector or LanceDB, then embed the query and rank by similarity. We wrote up the details of semantic search with LanceDB and pgvector, including when to pick which.

Most teams are surprised by where the cost goes. Embeddings are cheap: OpenAI's text-embedding-3-small is $0.02 per million tokens, so even 100 million tokens of code is about $2. The expensive parts are everything around the model: chunking that respects code structure, re-embedding only what changed on each push, permissions, ranking that mixes exact matches with semantic ones, and evaluating whether results are any good. Pure vector search is also weak at exact matching, which grep does well. Searching ERR_TOKEN_EXPIRED should find that exact string, and a similarity score won't promise that, so in practice you end up running a lexical index as well.

The build-vs-buy cost table

The scenario is 50 engineers and 200 repositories, all on GitHub, in year one.

These are the assumptions, so you can swap in your own:

• A loaded engineer (salary plus overheads) costs $100 an hour. If your rate differs, multiply the hours column by it and add the cash column.
• Compute is AWS on-demand list price, 730 hours a month: m6i.xlarge (4 vCPU, 16 GiB) at $0.192 an hour for lexical search, r6i.2xlarge (8 vCPU, 64 GiB) at $0.504 an hour when you also run a vector database.
• Hours are our estimates for a competent engineer who hasn't built this before. They are ranges because they depend on how strict your permission model is.

Cash is almost never the deciding number. The zoekt build has the smallest bill and still lands in the same range as a paid product once you count hours.

Those hours also come with on-call duty: if your search box goes down during an incident, whoever built it gets paged. The semantic build is the one people underestimate most, because the model call is so cheap that the rest of the system feels free.

Our view: build only if search is part of a product you sell, or your compliance rules rule out every option above. Otherwise, start with GitHub code search, and when the 100-result cap or the default-branch limit starts costing you, pick between a self-hosted zoekt product and Sourcegraph based on how many code hosts you have.

Where repowise fits

repowise answers the questions search alone cannot: how a feature works, what depends on a file, who owns it and what broke it before. It parses each repository into a dependency graph (28 languages to a full AST), adds git history, and serves hybrid search (identifiers, paths and plain-English questions) over generated docs, symbols and source lines. search_codebase returns exact identifier and literal matches with definitions first, and get_answer gives a cited answer to a how or why question.

The index runs on your machine or CI under AGPL-3.0, with no model needed for the search itself, and the same index is open to coding agents through ten MCP tools. It sits beside the tools above rather than replacing them: use GitHub code search or Sourcegraph for "every occurrence of this string across the org", and repowise for "explain this subsystem". The repowise vs Sourcegraph post goes deeper on the overlap, and what is codebase intelligence covers the category.

Which one to pick

• Pick GitHub code search if your code is on github.com and you need current-code lookups with regex, path: and symbol: filters.
• Pick Sourcegraph Enterprise if you have several code hosts, need every branch, compiler-accurate navigation across repos, or Batch Changes, and a $16K-plus contract fits.
• Pick Sourcebot if you want zoekt with a UI, multi-host sync and your code kept in your own deployment, without building it.
• Build on zoekt or embeddings only if search is product infrastructure you will staff, or compliance rules out the rest.
• Add repowise if you want explanations, ownership, health and agent access on top of search.

Try it

Index any public repository on the repowise homepage with no account, or open search on FastAPI. To run it locally: pip install repowise, then repowise init in your repo. Run the same questions through GitHub code search and judge the answers side by side.

How we measured

On 12 October 2026 we read the pricing and documentation pages of GitHub, Sourcegraph, Sourcebot, AWS (through instances.vantage.sh) and OpenAI, and checked licences and archive status through the GitHub API. The engineer-hour figures are our estimates, not measurements of any team, and the totals move a lot with your hourly rate and your permission model. The post compares cost and capabilities, not result quality on your code.