Neon adds built-in hybrid search

This moves Neon from being only a database host to being the place where an app can store records, embeddings, and search indexes in one system. In practice that means a developer can keep product data, document chunks, and app metadata in Postgres, then run keyword search, filters, and vector search without copying data into Elasticsearch. That is a simpler stack, with fewer sync jobs, fewer failure points, and more spend captured inside one Neon deployment.

• pg_search adds the parts of search teams usually leave Postgres to get elsewhere, including BM25 ranking, typo tolerance, faceting, and JSON aware filtering. Neon says it is available as a Postgres extension on Neon, so search becomes another database feature instead of a second distributed system to operate.
  2 neon 3 neon
• The real prize is hybrid search for AI apps. A RAG app often needs semantic matching on embeddings plus exact keyword matches on names, codes, and filters like date or category. Putting both vector and keyword search near the same rows reduces data movement and makes retrieval logic easier to build and tune.
  1 sacra 4 sacra
• This also sharpens Neons position versus adjacent developer database platforms. Supabase wins with a broader backend bundle around auth and storage, while PlanetScale has pushed into vector search on its own database platform. Search inside Neon gives it one more reason for AI app teams to keep the operational database as the center of the stack.
  1 sacra 5 sacra 6 sacra

The next step is a broader shift from separate database plus search architectures toward Postgres as the default retrieval layer for many application workloads. If Neon keeps pairing serverless economics with built in vector and keyword search, it can absorb more of the cloud search budget that previously sat outside the database.