I would first ask why they want to move. Lower cost, simpler access control, one source of truth, transactional updates, fewer services? Each gives a different success test. “Postgres can do vectors” and “managed search scales” are both too vague. The decision depends on how many vectors each tenant has, how much of that set survives a real query's filters, query rate and concurrency, update rate, target recall and p99, and what the team can operate during an incident.

For small tenants with highly selective filters, the surprising answer may be to avoid approximate vector search for those queries. A B-tree or partitioning scheme can first find a small authorized subset, then calculate exact vector distances over it. That gives exact nearest neighbors within that subset and may be cheaper than exploring an approximate graph that later discards most hits. pgvector's index guidance explicitly notes that approximate index filtering is applied after the index scan and describes iterative scans, filter indexes, and partitioning as ways to handle selective filters. The right plan depends on cardinalities. EXPLAIN (ANALYZE, BUFFERS) on representative queries is more useful than a generic ANN benchmark.

Be careful with the phrase “filter first.” It must mean the database executes a plan over the permitted subset, not that the application retrieves global neighbors and drops forbidden rows afterward. With an HNSW index, selective filters can leave fewer than k returned candidates. Increasing the scan budget or using iterative scans may improve recall at added latency and work. A query-specific exact path over a small filtered set can be better. Test both with the same authorized relevance labels and the same metadata predicates.

PostgreSQL also changes the operational shape. Vector indexes consume memory and write/maintenance resources. Tenant count, skew, embedding dimension, index build time, replication lag, vacuum pressure, backups, failover, and noisy queries matter. A separate table or partition per tenant can isolate a few large tenants, but thousands of tiny tenant partitions have their own planning and maintenance cost. If row-level security is in scope, verify the actual query plan and connection identity. PostgreSQL row security policies can enforce row visibility, but the application still has to bind the correct user and handle privileged roles carefully. Database security isn't a substitute for source permission freshness.

I would replay production-shaped queries against both systems from the same corpus revision. Include a broad semantic query, an exact identifier query if this service also does lexical search, a tiny tenant, a large tenant, very selective permissions, rapid updates, and permission revocation. Measure answer-bearing recall at a fixed latency and candidate budget, p50/p95/p99 under concurrent writes, freshness, cost per useful answer, and operational recovery time. Count the work needed to provide hybrid search, reranking, observability, and backfill in either architecture. A vector-only comparison can miss most of the product.

The interviewer makes tenants small and filters selective. I would prototype Postgres with the exact filtered path first. If its p99 and write contention remain within target, one fewer serving system may be worth a lot. I would still carve out the large-tenant and broad-search tails. If they dominate capacity or need specialized indexing, a managed service can remain for those slices, provided the split does not produce inconsistent authorization or two citation identities. Do the migration with shadow reads and source-version parity, then switch by tenant cohort. A cost estimate from a quiet day is not a migration argument.