{"slug": "commsync-runs-text-vector-and-hybrid-search-on-postgres-with-lakebase-search", "title": "CommSync Runs Text, Vector, and Hybrid Search on Postgres with Lakebase Search", "summary": "CommSync, a unified inbox platform for business messaging, achieved a 1,000x query latency improvement by replacing its GIN-based search with Neon's Lakebase Search extensions, lakebase_text and lakebase_vector, across three product features. Co-founder and CTO Srijit Ghosh reported warm query latency of 18.6ms versus 19.5 seconds on the old cold-start GIN approach. The company now runs pure text search via BM25, vector search for semantic queries, and hybrid search using Reciprocal Rank Fusion, all on Postgres without a separate search stack.", "body_md": "\"We're running lakebase_text and lakebase_vector across three different parts of our product. Query latency improved 1,000x and we don't need a separate search stack sitting next to our Postgres\"\n\nSrijit Ghosh, Co-founder and CTO at CommSync\n\n[CommSync](https://commsync.ai/) gives business owners one inbox for every conversation, threading SMS and email from every channel into a single view. It makes life simple for professionals that need to keep an eye on different people and operations all at once, e.g. wedding planners, brokers, med-spas...\n\nThe nature of the CommSync product means there's a need for search across a high volume of messages in different formats - search is a core product surface for them. To build this, CommSync chose Neon's new [Lakebase Search](https://neon.com/docs/ai/lakebase-search) extensions, [lakebase_text](https://docs.databricks.com/aws/en/oltp/projects/lakebase-text) and [lakebase_vector](https://neon.com/docs/extensions/lakebase-vector).\n\n## Three search boxes, all powered by Postgres\n\n\"Using Lakebase Search, we clocked around 18.6ms warm, versus around 19.5 seconds on our old cold-start GIN approach. That's a 1,000x improvement\"\n\nSrijit Ghosh, Co-founder and CTO at CommSync\n\nCommSync runs search in three different features, each one with different requirements:\n\n### Main inbox search: pure text search, highest traffic\n\nThis is the highest-traffic search path in the product by far, encompassing both the fast typeahead and the full results page.\n\n**This path runs BM25 via lakebase_text over message and attachment text.** CommSync's old GIN/tsquery implementation is still in place as an automatic fallback for any compute where the extension isn't available\n\n*[Editor's note: Lakebase Search*.\n\n[launched recently on Neon](https://neon.com/blog/lakebase-search-on-neon)]### AI assistant: vector search end-to-end\n\nCommSync's in-app AI assistant can also search the inbox by meaning instead of keyword, handling queries like \"find the thread where someone complained about pricing\".\n\n**This path runs lakebase_vector end to end**, with cosine similarity over 1024-dimension embeddings,\n\n`qwen3-embedding-8b`\n\nas the primary model, and `bge-m3`\n\nas a same-dimension fallback.### Command palette: hybrid search\n\nThis new feature just shipped: CommSync's cmd+k command. Here, the two previous search paths meet:\n\nCommSync built this feature on the standard shape of Reciprocal Rank Fusion (RRF):\n\n- Each keystroke fans out to a lexical arm (\n`lakebase_text`\n\n/BM25) and a semantic arm (`lakebase_vector`\n\n), each returning its own ranked list of matching conversations. - The two lists are fused with the textbook RRF formula:\n`score = sum of 1/(k + rank)`\n\nacross arms, with`k=60`\n\n. - The one deviation from vanilla RRF is weighting: lexical gets 1.0, semantic gets 0.8, so an exact keyword match still wins ties against a conceptually-similar-but-not-literal semantic hit. Given how much traffic the fast lexical path above carries, that felt like the right default.\n- A third, unfused arm handles attachment matches, using trigram plus text search over extracted file text.\n- The semantic arm only engages once a query is past 3 characters, to avoid burning embedding calls on noise.\n\nTo keep the command responsive, CommSync runs this in two tiers:\n\n- A fast lexical-only pass on every keystroke (around 110ms latency),\n- Followed by a debounced deeper pass that folds in the semantic arm and replaces the list once it lands (around 420ms latency). Staleness guards make sure a slow response never overwrites a newer one.\n\n## Beyond search boxes: CommSync Agents run RAG on lakebase_vector\n\nCommSync also recently shipped CommSync Agents: AI responders a business configures to automatically answer inbound texts and emails on chosen lines - with draft, supervised, and fully autonomous modes, and human takeover at any moment.\n\nBefore an agent answers a customer, it retrieves from an org-level knowledge base: uploaded documents and crawled website pages, chunked and embedded into the same Postgres database that holds the rest of CommSync's data. This knowledge base runs entirely on `lakebase_vector`\n\n: the same 1024-dimension embeddings and cosine-distance operators as the inbox's semantic search, reused wholesale.\n\n\"Our agents' knowledge base is just another table. Retrieval is a cosine top-K where tenancy and each agent's document whitelist are WHERE clauses in the same query. There's no second vector database to mirror our permission model into\"\n\nSrijit Ghosh, Co-founder and CTO at CommSync\n\nBecause everything is pgvector-compatible SQL on one database, CommSync gets to pick the right retrieval strategy per corpus: the shared inbox index (hundreds of thousands of message chunks) uses the `lakebase_ann`\n\nindex for approximate nearest-neighbor speed, while each organization's knowledge base (capped at a handful of documents) runs exact nearest-neighbor with no index at all, trading nothing for perfect recall. One extension, two strategies, chosen table by table.\n\n## Behind it all: Lakebase Search\n\nCommSync could build all three search features directly in Postgres thanks to Lakebase Search. Running on [Neon](https://neon.com/), the team turned to Lakebase Search for a performance boost, rather than wiring up separate search and vector databases or relying on Postgres' native GIN/pgvector implementations. [Lakebase Search](https://neon.com/docs/ai/lakebase-search) bundles two Postgres extensions, `lakebase_vector`\n\nand `lakebase_text`\n\n:\n\n`lakebase_vector`\n\nadds the`lakebase_ann`\n\nindex type for approximate nearest-neighbor vector search. It's a drop-in for pgvector: same types, distance operators, and query syntax, so existing queries work unchanged.`lakebase_text`\n\nadds the`lakebase_bm25`\n\nindex type for BM25 full-text search. It works with standard`tsvector`\n\ntypes and operators, adding true BM25 relevance scoring and top-K pushdown that native GIN indexes don't support.\n\n\"The auto-detection of lakebase_text in shared_preload_libraries at boot made rollout painless. We didn't have to hardcode a feature flag per environment\"\n\nSrijit Ghosh, Co-founder and CTO at CommSync\n\nUsed separately, the two extensions cover text search and vector search. Used together, they support hybrid search, combining exact-term precision with conceptual recall in a single query path on the same Postgres database that already holds the rest of the application's data.\n\n## Get started\n\nIf your app needs both keyword and semantic search and you'd rather not run a separate search cluster to get it, [Lakebase Search](https://neon.com/docs/ai/lakebase-search) is available now on Neon. [Open a free account](https://console.neon.tech/signup) and enable the extensions on your existing project, or even better, [tell your agent to do it for you](https://neon.com/docs/introduction).\n\n**A big thank you to Srijit Ghosh and the CommSync team for building on Neon and sharing their experience with Lakebase Search. You can try CommSync for free.**", "url": "https://wpnews.pro/news/commsync-runs-text-vector-and-hybrid-search-on-postgres-with-lakebase-search", "canonical_source": "https://neon.com/blog/commsync-runs-text-vector-and-hybrid-search-on-postgres-with-lakebase-search", "published_at": "2026-07-30 12:00:00+00:00", "updated_at": "2026-07-30 16:45:18.219362+00:00", "lang": "en", "topics": ["artificial-intelligence", "large-language-models", "ai-products", "ai-infrastructure", "developer-tools"], "entities": ["CommSync", "Srijit Ghosh", "Neon", "Lakebase Search", "lakebase_text", "lakebase_vector", "BM25", "Reciprocal Rank Fusion"], "alternates": {"html": "https://wpnews.pro/news/commsync-runs-text-vector-and-hybrid-search-on-postgres-with-lakebase-search", "markdown": "https://wpnews.pro/news/commsync-runs-text-vector-and-hybrid-search-on-postgres-with-lakebase-search.md", "text": "https://wpnews.pro/news/commsync-runs-text-vector-and-hybrid-search-on-postgres-with-lakebase-search.txt", "jsonld": "https://wpnews.pro/news/commsync-runs-text-vector-and-hybrid-search-on-postgres-with-lakebase-search.jsonld"}}