Ask AI in plain language. Get a chart, a grid, or a reviewed change.
Parley is an AI chat layer over the databases you already run. One conversation drives reporting, visualization, tabular editing, and bulk data management, and the model never decides what is safe to write.
The questions arrive faster than the queries.
Business intelligence tools want to copy your data into their store and have you maintain a modeling layer. Notebooks answer one analyst’s question, once. Neither lets anyone safely fix the row that is simply wrong, so corrections happen in a spreadsheet, or in psql at six in the evening.
Ask the one person who writes SQL
Every question about the data becomes a ticket in someone else’s queue.
Wait for the extract
A CSV arrives, already stale, cut off from the database it came from.
Fix it by hand and hope
A cleaning UPDATE runs against live data with no way to see what it will touch.
One conversation, four modes
How it worksReport
Ask a data question and get a visualization that answers it. The AI writes the SQL and the chart configuration: sixteen chart types, from bar and line through sankey, treemap, heatmap, and geographic maps. Pin the ones that prove useful into folders the team or public sharing.
Table
A spreadsheet-like grid over any query, with editors derived from your schema: enums become dropdowns, foreign keys become pickers that show a label and store an id, and a null renders as a distinct ∅ rather than an empty cell.
Data Manager
Describe a bulk change, like "archive every survey still pending from before 2020", and read a row-by-row diff of exactly what it would do, cascades and your own triggers included, before deciding whether to apply it.
Schema
Browse tables, views, and columns, and manage the data dictionary directly in the database as comments, where every other tool can read it too. Slice and dice access to your database via in-tool schemas and expose only what you want the AI to understand.
The model proposes. Your schema disposes.
A language model is a capable writer and a poor authority. Parley lets it do the generative part, turning a question into a candidate query, while a deterministic engine derives every safety-critical answer from your schema’s own keys, relationships, and grants: what is editable, how to write it back, what a change would touch. A bad guess produces a wrong-but-harmless result or a read-only grid. It cannot produce silent corruption.
It attaches to your database. It never absorbs it.
Parley connects out to a database you own and keeps its own state (conversations, pinned views, audit trail) on its side of the line. Nothing tool-owned is written into your data: no extra columns, no bookkeeping rows, no permanent triggers. The change preview runs inside a transaction that is rolled back, so it leaves your schema byte for byte as it found it.
Your grants are the boundary. What the connection role is permitted to do is exactly what Parley can do, and the database enforces that, not our code.
Lift the software off and a complete, rational dataset remains. You lose your pins, not your data.
What Parley does
Grouped by concernQuestion to chart
Plain language in, SQL and a rendered visualization out.
Sixteen chart types
Bar through sankey, treemap, heatmap, and maps.
Pinned and shared
Save the shapes that prove useful into shared folders.
Schema-driven editors
Dropdowns, pickers, and null handling derived from your types.
A visible change trail
Every edit stays marked, and anything marked can be restored.
Diff before apply
Bulk changes are reviewed as rows, not trusted as SQL.
Grants decide capability
Read, write, and preview follow the role you connect with.
Audit outside your tables
Who changed what, recorded without touching your data.
Documentation that stays
The data dictionary lives in the database, readable by any tool.
Who Parley is for
By situationYour team waits on you for every number
You can write the query in two minutes, but you are the queue, and the questions never stop arriving.
Someone capable is editing production directly
Not recklessness: raw SQL is simply the fastest road under a deadline. The paved road has to be faster, and safer.
The data is not yours to hand over
You hold it under a data-sharing agreement, so portability and non-lock-in are contract terms, not preferences.
Why not just use an existing tool?
Comparison| Parley | BI platforms | Notebooks | Raw SQL | |
|---|---|---|---|---|
| Runs on the database you already own | Native | Copies to its store | ✓ | ✓ |
| Natural-language questions | ✓ | Sometimes | — | — |
| Corrects data, not just reads it | ✓ | — | — | ✓ |
| Row-level diff before a write | ✓ | — | — | — |
| Safety derived from the schema | ✓ | — | — | Your judgement |
| Modeling layer to maintain | None | Required | — | — |
| Leaves nothing installed in your database | ✓ | Varies | ✓ | ✓ |
Managed hosting
No infrastructure to run. Parley connects out to your database over a credential you issue, and that you can revoke in a single statement.
On-premises / self-hosted
For residency, compliance, or governance requirements. Runs entirely inside your infrastructure, against a model provider key you control.
Curious what it would make of your schema?
Tell us what your data looks like and what you keep having to ask it. We’ll show you the round trip.