Search — Full-Text, Semantic, and Instant

Every Synap pod has three search layers working together: full-text search for instant keyword matching, semantic search for finding things by meaning, and structured queries for precise property filtering. You never have to choose — they all run simultaneously.

Layer 1: Typesense — Full-text search

Typesense provides instant, typo-tolerant full-text search across every entity in your pod. As you type, results appear in milliseconds. Typesense handles misspellings gracefully — searching "reciepe" still finds your "Recipe" entities. It also supports faceted search, meaning you can filter results by profile type, date range, or any indexed property while searching.

Every entity's title, description, and text content are indexed automatically when created or updated. There is no manual indexing step — Typesense stays in sync with your PostgreSQL data through background jobs managed by pg-boss.

Layer 2: pgvector — Semantic search

Sometimes you do not remember the exact words, but you remember the meaning. Semantic search powered by pgvector lets you find entities based on conceptual similarity. Search for "that paper about distributed consensus" and it will find an article titled "Raft: In Search of an Understandable Consensus Algorithm" — even though the query shares almost no keywords with the title.

Semantic search works by generating vector embeddings of your entities' content and storing them directly in PostgreSQL using the pgvector extension. When you search, your query is also converted to a vector, and the database finds the closest matches using cosine similarity. This runs entirely within your pod — no data leaves your server.

Embeddings are generated asynchronously when entities are created or updated. The embedding model runs through the intelligence service, and the resulting vectors are stored alongside your regular data in PostgreSQL. This means semantic search benefits from the same backup, replication, and access control as all your other data.

Layer 3: PostgreSQL — Structured queries

For precise filtering, PostgreSQL handles structured queries directly. Need all tasks with status "in-progress" created after March 1st? That is a direct SQL query against the JSONB properties column, executed through Drizzle ORM. PostgreSQL excels at exact matches, range queries, and complex property filters that full-text and semantic search cannot express.

View filters use structured queries under the hood. When you add a filter to a table view ("status is done AND priority is greater than 3"), that translates to a PostgreSQL query. This is why view filtering is always precise and instant, regardless of how many entities you have.

How they work together

When you type a query in Synap's search bar, all three layers activate in parallel. Typesense returns instant keyword matches. pgvector returns semantically similar results. PostgreSQL applies any active filters (profile type, date range, workspace scope). The results are merged, deduplicated, and ranked — keyword matches and semantic matches appear together, with relevance scoring that considers both exact keyword overlap and meaning similarity.

This multi-layer approach means you always find what you are looking for, whether you remember the exact title, a rough description of the content, or specific properties. Search is the fastest way to navigate a large pod, and it gets smarter as you add more data — more content means richer semantic connections.

Indexing is automatic

You never need to manually trigger indexing or rebuilding. When an entity is created, updated, or deleted, background jobs update the Typesense index and regenerate vector embeddings as needed. The system uses pg-boss for reliable job processing, ensuring that even during high-volume imports (like a connector sync pulling hundreds of calendar events), every entity gets indexed without overwhelming the system.

Related guides