cost per active user hit $1.90 on a $9 plan after adding pgvector search Unit Economics

Re-embedding on every save is the whole $402 and it's the easiest thing on your list to fix.

Chunk first, hash each chunk, store the hash next to the vector. On save, re-chunk, and only send chunks whose hash changed. Someone editing paragraph 4 of an 11-paragraph note re-embeds one chunk, not eleven. Our re-embed volume dropped 94% and the quality is identical because the unchanged text produces the identical vector anyway.

Second, debounce. There is no reason to embed on keystroke-save. Queue it, coalesce, run 30 seconds after the last edit. Combined with hashing that took us from ~180k embed calls a day to about 6k.

Third, check whether your embedding model supports shortened output dimensions. If it does, going from 1536 to 768 halves your index size and your index build time with a small retrieval quality hit that is usually invisible for a notes product. Measure it on your own data before you commit, obviously.

Cache the query embeddings too, not just the document ones. In our logs about 38% of searches in any given week are a string we have embedded before - people re-run the same search, or five users in a team search the same project name. A hash-keyed cache with a 30 day TTL is twenty lines and shaves real money off the API line.

The Postgres jump is almost certainly index maintenance, not queries. HNSW insert is expensive - every new vector walks the graph and updates neighbour lists. If you are re-embedding 180k chunks a day you are doing 180k HNSW inserts a day on top of your normal write load, and the CPU for that is not free.

Turn on pg_stat_statements and look at total_exec_time ordered desc. My bet is you see the INSERT/UPDATE on the vectors table well above any SELECT.

Other things worth checking:

• maintenance_work_mem during index build. If it is too small the build spills and takes forever, burning compute the whole time.
• whether you are rebuilding the index rather than incrementally inserting. A full HNSW build on a few million vectors with default m=16, ef_construction=64 is hours of pinned CPU.
• your autovacuum settings. High-churn vector tables bloat fast and nobody notices until the instance is 3x the size it should be.

Fix the re-embed volume and the Postgres bill probably fixes itself as a side effect.

Engineering answers aside, you also have a pricing problem. "$9/mo, unlimited semantic search over unlimited notes" is a promise where your cost scales with usage and your revenue does not. That is fine at 640 users and fatal at 6,400.

You do not need usage-based billing tomorrow. You need a limit that is generous enough that 95% never see it and real enough that the tail cannot ruin you. Something like 2,000 indexed notes on the $9 plan. Ship it for new signups, grandfather everyone existing, and now your worst case is bounded.

Honestly for notes, tsvector full text search is free, runs on the same box, and handles maybe 90% of what people actually search for. The vector stuff is a lot of cost for the last 10%.

$1.90 CPAU on a $9 plan is survivable. The version of this post I was expecting had a $3 plan.