The essentials
Aurabase: native pgvector (3 dimension classes 768/1536/3072), RAG integrated via ragIngest()/rag(), and above all a native NL2SQL endpoint validated by syntactic tree. Convex and Nhost both offer solid vector search — but neither exhibits native NL2SQL in the strict sense: translating a natural language question into a validated, bounded SQL query, executed as read-only.
The differentiator that neither competitor covers
The Aurabase NL2SQL endpoint validates each query generated by an LLM via a syntax tree (crate sqlparser): only SELECT, a list of authorized functions, a bounded LIMIT by default, and an explicit rejection of schema fields that the client would try to usurp. This is not a connector assembled on top of the backend — this is verified in the aura-aicode.
Convex has no equivalent — its database is not SQL, the question is not asked in the same terms. Nhost offers an AI assistant with access to the GraphQL schema, but not an NL2SQL endpoint exposed to your end users with a documented security contract. See our complete definition of NL2SQL and our article on securing against SQL injection generated by an LLM.
native pgvector, without separate vector base to operate
Aurabase embeds pgvector directly into its Postgres 16 tenant image, with a native RAG pipeline — ingestion, chunking, embeddings, HNSW index per dimension class — exposed via two API calls, ragIngest() and rag(). See our complete RAG pipeline tutorial.
Convex offers robust embedded vector search, with reusable RAG and Agent components and configurable OpenAI embeddings support. Nhost automatically generates and maintains vector embeddings for semantic search. All three platforms cover this ground — the difference is in what comes after the vector search, not the search itself.
Three native clients, not a generic router
Aurabase natively integrates OpenAI, Anthropic and Gemini — each with a dedicated client in aura-ai, with automatic circuit breaker failover in the event of a provider failure. See our article on native providers vs OpenAI compatible endpoints for the exact details of this distinction.
What distinguishes the three AI approaches
| Native NL2SQL | Yes — validated by syntax tree | No (Convex, Nhost) |
|---|---|---|
| Vector search | native pgvector, HNSW per dimension | Yes, solid in both |
| RAG | Native, 2 API calls | Reusable components (Convex) |
| Database | PostgreSQL 16 standard | Non-SQL (Convex) / Postgres+Hasura (Nhost) |
| Native LLM Providers | 3 (OpenAI, Anthropic, Gemini) | Undocumented equivalent |
Convex and Nhost are truly investing in their respective AI capabilities — their vector search is mature and documented. Native NL2SQL remains, to this day, ground that neither of the two covers in the strict sense.