For 95% of standard search use cases (text search, typo tolerance, filtering) up to 10M rows, PostgreSQL with this SDK is faster and drastically cheaper. You only need ES if you require complex aggregations or faceted navigation on petabytes of data.

No. The Zombie Query Prevention mechanism uses AbortController. If a fast strategy resolves, slow queries are immediately cancelled via AbortSignal, freeing up DB connections and preventing table locks.

It uses a Smart Hybrid Fallback. If standard FTS fails, it falls back to Trigram fuzzy matching, which natively handles misspellings. It also handles keyboard layout errors (e.g., typing Russian on an English layout) using ISO 9 standardization.

Yes. By installing the pgvector extension and configuring OpenAI/Gemini API keys, the engine can perform vector similarity search on the VECTOR tier. That tier is exclusive — a single call either runs FTS/trigram (other tiers) or vector search (VECTOR tier), not both at once. Combining them means running two engines against the table and merging results yourself.

Absolutely, for injection specifically: the engine uses parameterized queries for all values and a strict SqlSanitizer safe-identifier check for SQL identifiers (tables, columns, and dynamic filter keys) — anything that isn't a plain alphanumeric/underscore identifier is rejected before a query is built. Note this is a syntactic check, not a schema or allowlist check: it doesn't verify the column exists, and it doesn't restrict which columns callers are allowed to filter on — if you build filters from user input, map it to an explicit allowlist yourself first.