Choose how to query your data
Start with the question your application needs to answer. Use the table below to choose a query method and see what data to prepare.
- Identify what mattersExact values, similar meaning, words or relationships?
- Choose the query modelUse SQL, vector, full-text or graph for that question.
- Prepare its dataCreate the required fields, indexes or relationships.
- Check known matchesStart with results you can verify by hand.
Match the question to a tool
| Question | Use | Prepare first |
|---|---|---|
| Which orders are paid? What is the total by customer? | SQL | Typed rows, appropriate indexes and tested joins or aggregates. |
| Which documents mean something similar? | Vector search | Embeddings from one model with matching dimensions and metric. |
| Where does this phrase or product code appear? | Full-text search | Indexed text and an appropriate analyzer. Use a structured filter when an identifier must match exactly. |
| Who is connected to this account? Can one node reach another? | Graph traversal | A declared relation or supported edge mapping. |
| How can someone ask about data in plain English? | Ask | Registered schemas, permission-scoped context and review of the compiled plan. |
Understand what is kept in sync
A row write maintains the indexes attached to that row operation, including its declared graph relations. Explicit vector-table and full-text document calls are separate operations. Generating an embedding is also separate work; use a configured run or schedule, or your application.
Use one stable source ID across the models and track incomplete index work. There is no blanket guarantee that a sequence of row, vector and full-text HTTP calls commits as one transaction. See write boundaries.
Combine models when the question needs it
- Combine word and meaning search: run full-text and vector queries, combine their rankings in your application, then fetch the matching records. Test with questions your users actually ask.
- Combine links and filters: follow a graph relationship to get record IDs, then use SQL to select the fields and rows you need.
- Give an AI answer supporting evidence: retrieve relevant content, keep its source IDs and pass only permitted content to the model. This is retrieval-augmented generation (RAG). See the RAG guide.
Check feature scope
SQL supports more than simple filters: supported CTE, join, window, ORDER BY and HAVING shapes exist. Each has limits; use the SQL guide and GET /v1/capabilities for your deployed engine. Ask’s compiler does not automatically expose every SQL feature.
Check permissions for each API under the application’s database identity. Sharing a record ID or bearer token is not proof that every query surface applies identical access rules.
Start with one working query
Run the first-query quickstart, then add a vector or graph workflow when your application needs it. Use representative data to measure relevance, latency and result correctness before adding another query model.