AI Vision & Attachments
Use images as part of the AI context: ERDs, whiteboards, app screenshots, and hand-drawn diagrams can be analyzed to generate SQL, MQL, structure explanations, or the next step.
Images are real context
Attachments are not decorative. They travel through a vision-capable request path so AI can read diagrams, in-image text, or UI structure that matters to the task.
The output is not just image description
The result can be SQL, MQL, a schema explanation, or a quick read that tells you whether to continue in the builder, the query editor, or a chart flow.
The provider must match the capability
Not every AI lane in the app can understand images. Only the lanes that the repo marks as vision-capable are allowed to handle attachment-based prompts.
What a good vision workflow looks like
If the goal is SQL, stay in the SQL workspace. If the goal is MongoDB/MQL, stay in the NoSQL workspace. The same image can lead to different useful output depending on the workspace.
Do not stop at “look at this image.” State whether you want schema generation, relationship explanation, query generation, or a specific fact extracted from the image.
Images can be blurry, incomplete, or inconsistently labeled. Even when AI reads them well, you should still review the SQL/MQL before insertion or execution.
A good ERD screenshot can take AI surprisingly far, but decisions like data types, indexing, nullability, and production policy still need human confirmation.
Which vision providers are trustworthy in the current repo?
Gemini
The strongest and most stable default vision lane in the current repo. This is the safe choice when image quality matters more.
OpenRouter
Can serve as a vision path when the chosen model truly supports images. Because OpenRouter is a multi-model lane, the capability depends on the selected model rather than the provider label alone.
What vision does not replace
It does not replace query review
Even when the image is read correctly, SQL or MQL generated from that image should still be reviewed before insertion or execution. A good image makes the workflow faster, not review-free.
It does not become live web search automatically
Attaching an image does not magically give the model internet access. Vision and live search are different capabilities. A lane can read images well and still be unable to answer with real-time web data.
It does not turn an image into absolute truth
An ERD, screenshot, or sketch can omit fields, miss relationships, or drift from the real system. Vision is great for a fast start, but live data and the real schema remain the final source of truth.
Which image types work best?
ERDs and data diagrams
Great for SQL DDL generation, relationship explanation, entity discovery, and initial schema scaffolding.
Whiteboards, notes, and sketches
Useful for turning rough ideas into a first draft of tables, fields, or exploratory queries.
App screenshots
Helpful when you want AI to infer the data shape behind a form, UI table, report screen, or business flow.
A true vision lane is required
To use image attachments with the current wiring, you need at least one of: `GEMINI_API_KEY` or `OPENROUTER_API_KEY`. Without a vision-capable lane, the app rejects image-based tasks.
Practical tip: if the image contains important text, keep it sharp, crop it to the relevant area, and state the expected output clearly. For example: “Generate a PostgreSQL schema”, “explain the relations”, “read the exact text in the image”, or “turn this form into a collection design”.
Ready to explore data?
Join the community on GitHub to contribute to the smartest local database IDE.
Launch App