필수사항
Aurabase: 기본 pgVector(3차원 클래스 768/1536/3072), ragIngest()/rag()를 통해 통합된 RAG, 그리고 무엇보다도 구문 트리로 검증된 기본 NL2SQL 엔드포인트. Convex와 Nhost는 둘 다 견고한 벡터 검색을 제공하지만 둘 다 엄격한 의미에서 기본 NL2SQL을 표시하지 않습니다. 즉, 자연어 질문을 읽기 전용으로 실행되는 검증되고 제한된 SQL 쿼리로 변환합니다.
어느 경쟁사도 포괄하지 않는 차별화 요소
Aurabase NL2SQL 엔드포인트는 구문 트리(크레이트 sqlparser)를 통해 LLM에서 생성된 각 쿼리의 유효성을 검사합니다. SELECT만, 승인된 함수 목록, 기본적으로 제한된 LIMIT 및 클라이언트가 빼앗으려고 시도하는 스키마 필드의 명시적인 거부입니다. 이는 백엔드 상단에 조립된 커넥터가 아닙니다. 이는 aura-ai코드에서 확인됩니다.
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.
별도의 벡터 베이스 없이 작동하는 기본 pgVector
Aurabase는 ragIngest() 및 rag()두 개의 API 호출을 통해 노출되는 기본 RAG 파이프라인(수집, 청킹, 임베딩, 차원 클래스당 HNSW 인덱스)을 사용하여 Postgres 16 테넌트 이미지에 pgVector를 직접 포함합니다. 전체 RAG 파이프라인 튜토리얼을 참조하세요.
Convex는 재사용 가능한 RAG 및 Agent 구성 요소와 구성 가능한 OpenAI 임베딩 지원을 통해 강력한 임베디드 벡터 검색을 제공합니다. Nhost는 의미 검색을 위한 벡터 임베딩을 자동으로 생성하고 유지합니다. 세 가지 플랫폼 모두 이 분야를 다루고 있습니다. 차이점은 검색 자체가 아니라 벡터 검색 뒤에 오는 것입니다.
일반 라우터가 아닌 세 개의 기본 클라이언트
Aurabase는 기본적으로 OpenAI, Anthropic 및 Gemini를 통합합니다. 각각은 aura-ai의 전용 클라이언트와 함께 공급자 오류가 발생할 경우 자동 회로 차단기 장애 조치를 수행합니다. 이러한 차이점에 대한 정확한 세부 정보는 기본 공급자와 OpenAI 호환 엔드포인트에 대한 기사를 참조하세요.
세 가지 AI 접근 방식의 차이점
| 네이티브 NL2SQL | 예 — 구문 트리로 검증됨 | 아니요(볼록형, Nhost) |
|---|---|---|
| 벡터 검색 | 기본 pgVector, 차원당 HNSW | 네, 둘 다 확실해요 |
| 걸레 | 네이티브, 2개의 API 호출 | 재사용 가능한 구성요소(볼록형) |
| 데이터베이스 | PostgreSQL 16 표준 | 비SQL(Convex) / Postgres+Hasura(Nhost) |
| 네이티브 LLM 제공업체 | 3(OpenAI, Anthropic, Gemini) | 문서화되지 않은 동등물 |
Convex와 Nhost는 각각의 AI 기능에 진정으로 투자하고 있습니다. 두 회사의 벡터 검색은 성숙하고 문서화되어 있습니다. 네이티브 NL2SQL은 오늘날까지도 엄격한 의미에서 둘 중 어느 것도 다루지 않는다는 근거로 남아 있습니다.