When designing search functionality for a modern Software-as-a-Service (SaaS) platform, there is a common engineering reflex: immediately spin up a dedicated search cluster like Elasticsearch or Algolia. It is an easy default to fall back on, but in multi-tenant architectures, a "one-size-fits-all" search engine can quickly turn into an operational and financial bottleneck.

Recently, while architecting a scaling, multi-tenant fitness and SaaS creator platform, our team faced two entirely different search requirements. Instead of forcing a single external search engine to handle both, we designed a pragmatic hybrid search architecture.

By splitting the workload between Typesense for curated static templates and native PostgreSQL ts_vector for dynamic, user-generated content, we achieved lightning-fast search performance while keeping infrastructure costs and sync complexities down to a minimum.

---

The Dilemma: Two Radically Different Query Patterns

The platform had to support two distinct search behaviors, each with completely conflicting data profiles:

1. The Global Template Library (Static, Curated, High-Fidelity)

The platform features a global repository of a few thousand standardized templates curated by the platform administrators. Creators browse this library to set up their workspaces.

• Requirements: Highly responsive fuzzy search, semantic (vector) search, facet filtering, and manual "curations" (the ability for admins to manually boost specific templates to the top of search results).
• Data Profile: Static, relatively small dataset, read-heavy, and accessed globally across all accounts.

2. The Creator’s Workspace Search (Dynamic, Multi-Tenant, High-Write)

Each individual creator (tenant) has their own private workspace containing thousands of dynamically generated pages and blocks created by their end-users.

• Requirements: Fast, accurate full-text search within their own dashboard. It requires absolute data isolation: under no circumstance should a query from Tenant A leak results from Tenant B.
• Data Profile: Highly dynamic, constantly modified, and strictly isolated per tenant.

The Problem with "All-In" on Typesense

If we had pushed the dynamic, multi-tenant user-generated content (UGC) into Typesense, we would have faced a massive operational headache: maintaining and synchronizing thousands of separate Typesense collections (one for each tenant).

Continuous real-time database updates would trigger non-stop indexing write traffic to Typesense, leading to high RAM consumption, synchronization lag, and complex failure-recovery pipelines.

---

The Hybrid Solution: Architectural Segmentation

Our solution was to split the search engine based on the nature of the data: Typesense acts as our high-performance outward-facing search specialist, while PostgreSQL handles the transactional multi-tenant workload directly inside the core database.

1. Typesense for the Curated Template Library

Because the template library contains static, curated content, we indexed it into a centralized Typesense collection.

• Typesense effortlessly handles the full-text and vector embeddings search out of the box.
• Admins can easily set up rules to manually boost specific templates.
• Since the template data rarely changes, we only trigger a re-indexing background job when the underlying template schema changes, keeping write-overhead practically at zero.

2. PostgreSQL ts_vector for Dynamic Multi-Tenant Search

For the dynamic user-generated pages and blocks, we bypassed external indexing entirely and turned to Postgres’s native full-text capabilities.

• No Extra Infrastructure: By using PostgreSQL's ts_vector and a GIN index on the database we already run, we avoided the cost and complexity of spinning up a separate production-grade multi-tenant search cluster.
• Bulletproof Tenant Isolation: We naturally isolated search queries at the database query level using the existing account_app_id foreign key. There is zero risk of cross-tenant data leakage.
• Weighted Relevance: To make search results accurate, we utilized the ts_rank_cd() function with clear, business-driven weights:
  • Title (Weight A = 1.0): Best matches.
  • Tags (Weight B = 0.4): Secondary matches.
  • Body Content (Weight D = 0.1): Broad matches.
• Zero Sync Lag: Because the search runs directly on the transactional database, when a user edits a block, the change is searchable instantly. There is no background syncing pipeline to wait for or troubleshoot.

---

The Results: Simple Infrastructure, Invisible Overhead

By selecting the right tool for each specific query pattern, we achieved a highly optimized outcome:

• Zero Sync Overhead for UGC: The Progressive Web App (PWA) search requires no external index synchronization. It leverages the existing database connection pool, ensuring incredible query latencies and immediate consistency.
• High-Fidelity Discovery: The Template Library retains its rich, interactive search experience (with instant typing, fuzzy search, and semantic discovery) through Typesense.
• Drastic Infrastructure Cost Reductions: We avoided the massive RAM and storage costs associated with spinning up a distributed, multi-tenant Elasticsearch or Algolia cluster.

The Core Lesson: Avoid the "One Search Engine" Trap

This architecture highlights a key philosophy of our engineering team at NUS Technology: we prioritize pragmatic, scalable solutions over buzzword-driven complexity.

Before jumping into a massive, centralized search index, analyze the core characteristics of your data:

• Is it static or dynamic?
• Is it shared globally or strictly multi-tenant?
• What are the actual query patterns?

Evaluating these factors early can save your business thousands of dollars in monthly cloud bills and hundreds of hours in engineering maintenance.

---

Scale Your Operations without the Bloat

At NUS Technology, we don't just write code; we design robust Operations Backbone Platforms and Data & Intelligence Platforms that bend to your real-world workflows. We focus on architectural maturity—ensuring your systems scale smoothly, remain secure, and run highly cost-effectively.

If your current software infrastructure is becoming slow, unreliable, or prohibitively expensive to maintain as you scale, we can help.

Schedule a Strategy Session with NUS Technology today to discuss how we can optimize your operational platforms for sustainable, high-performance growth.