FluentDB

The AI database client for Mac

Productivity

Developer Tools

Artificial Intelligence

Visit WebsiteSee on Product HuntTwitter ⧉

Most of the thread is asking what AI can see. Mine is about how much: on a database with a few hundred tables, do you send the whole schema on every request, or is there a retrieval step that narrows it down first? Curious where suggestion quality starts dropping as table count grows, since that's usually where schema-aware tooling starts guessing at joins.

The Mac-native angle is interesting. I keep bouncing between SQL clients and browser AI tools, so having natural-language querying closer to the DB UI makes sense. Curious how you handle schema context when a workspace has multiple similar tables?

Congrats on the launch! A proper native Mac client is such a relief after living in Electron all day. Does it show you the query it is about to run before it runs it, or is that tucked away?

@rahulladumor that's exactly the scenario where the safety net matters most, honestly. confirm-each-query is naturally self-limiting since a human's eyes are on every write, but Auto run removes that friction entirely - if the row-count/WHERE-clause check doesn't carry over into that mode, Auto run for writes is basically running blind.

How are you thinking about prioritizing cross-platform vs. deepening the guardrails/safety features first? Curious whether early feedback like Brandon's is shifting your roadmap more than requests for new platforms at this stage.

The schema-only default with per-query approval is the right call — most AI database tools send sample rows to 'prove context' and that's the actual privacy leak, not the query. Two things I want to understand for local-first use: when talking to Ollama, does the schema introspection include column-level comments and check constraints, or just names and types? And for SQLite, is query execution going against the live file or does FluentDB open it in WAL mode with any read isolation to protect against a half-formed AI-generated write corrupting the journal?

Downloaded it and used it today really nice tool !

Feels fast and the UI is clean

Btw are you planning to support OLAP databases at some point (ClickHouse, DuckDB, BigQuery), or is the focus staying on OLTP for now?

Very interesting. I think the choice of native Swift is a big plus, especially compared to Electron-based solutions.

@rahul_ladumor good question, that's actually the scenario I'd worry about most - toggling auto-run for writes is exactly when you want the safety net most, not less. would be a strange design if convenience mode quietly removed the one check that matters for destructive queries.

the approval-by-default on write queries plus the read-only connection lock covers most of what I'd worry about. one thing I didn't see addressed - is there any kind of audit log of what got approved, so if something did go wrong (or you just want to know what the AI actually did to the db last week) you can look back at a history of generated queries and whether they were approved, edited, or rejected? feels like the kind of thing a team lead would want even if a solo user never touches it

Hi Kevin,
Hoe does it gather the actual context for what the data means ?
That has been the most diffucult thing for me, and would like to know about any plans for any lakehouse integrations ?

Congrats team! I have been burned before by an AI tool that wanted way too much access to my data, so the approval by default thing is really reassuring. Curious about the Ollama support, does the experience feel as smooth with local models or is it noticeably better with the bigger providers?

Cool, looking forward to try with my own product - I was user of TablePlus but it'd be great to have both table views + AI chat on top of my DBs

Nice one, native Swift instead of another Electron app is already a win for me. The schema only approach for the AI is the right call. When you say write queries need extra confirmation, can I lock it to read only mode entirely for certain connections?

The Ollama path is the obvious choice when the database has anything sensitive — inference runs locally, nothing leaves. One thing I want to understand: when you use a local model, what actually goes into the AI context? Is it the schema and the current query only, or do prior query results get included to give better suggestions? I'm wondering whether the opt-in read mode applies to local models the same way it does to cloud ones, or if the local boundary means results are always excluded.

@kevinpiacentini that confirm-before-execute default plus not sharing results back unless you opt into read mode is exactly the design I was hoping for, opt-in auto-run and opt-in read mode as two separate toggles is a nice way to let people dial in their own risk tolerance instead of one blanket switch. will check out the video, thanks for the detailed answer.

Every AI generated SQL query requiring approval by default is a genuinely good default, but curious how far the approval flow actually helps in practice, since a query can be technically correct and still catastrophic in effect. An UPDATE without a WHERE clause or a query that touches ten thousand rows instead of the intended one can look completely reasonable to someone glancing at the SQL text if they aren't reading it carefully in the moment. Does FluentDB do anything beyond just showing the raw query, like flagging when a generated query lacks a WHERE clause on an UPDATE or DELETE, or surfacing an estimated row count before you approve, since that's usually the gap between reviewing SQL and actually catching the dangerous ones. Also, models seeing your schema by default is a reasonable middle ground, but schema alone can still leak a fair amount, table and column names often describe exactly what kind of sensitive data lives there even without seeing a single row. Is there any way to selectively hide or rename specific tables and columns from what gets sent to the AI, for cases where even the schema shape is something a team wouldn't want leaving the machine.