DBarn — admin dashboard for your Konde data

Every database admin tool I have used had at least one of three problems: it was a separate app I had to context-switch into, it was a SaaS that wanted my production credentials, or it was so feature-rich that the daily-use surface was buried three menus deep.

DBarn is our answer. It is the database admin module bundled with Konde Studio v1.0.18 and later, and it is designed for one job: let a solo founder or tiny team see and edit their data without leaving Studio.

#What you get

When you connect a database (Postgres, SQLite, MySQL — MongoDB lands in v1.2), DBarn gives you a clean three-pane layout:

• Left: schema tree. Every table, every column, with type info on hover.
• Centre: row browser. Click a table, see the rows. Filter, sort, edit inline. Edits commit on tab-out.
• Right: SQL editor. Run any query against the same connection. Saved queries persist per-project.

That is the whole product. Three panes, one connection, no charts, no dashboards, no "data observability" upsell. If you want a chart, you want Metabase or Superset. If you want to stare at a table and tweak a row, you want DBarn.

#The thing that actually makes it useful

The reason DBarn exists as a Konde module — instead of, say, a recommendation to install Postico — is that agents see the same connection you do. When you ask an agent in Studio "what's the schema of my users table" or "draft a migration to add a subscribed_at column," the agent reads the schema directly from DBarn's connection. No retyping credentials. No agent running blind. No agent guessing column names.

Same in reverse: when an agent runs a migration, DBarn picks it up automatically. The schema tree refreshes. The row browser shows new columns. You see exactly what the agent did, without re-querying or re-loading.

#Safety rails

Three things stop agents from causing damage you did not authorize:

1. Read-only by default. Every connection starts in read-only mode. The agent can SELECT all day. To INSERT, UPDATE, or DELETE, you flip a switch per-connection.
2. Destructive query confirmations. DROP TABLE, TRUNCATE, DELETE without a WHERE — anything that nukes data — pops a confirmation in Studio. The agent waits.
3. Local snapshot before risky ops. When you authorize a destructive op, DBarn snapshots the affected tables to a local file you can roll back from. We are not going to save you from a deliberate DROP DATABASE on production, but for the typical "agent ran the wrong UPDATE" case, you have an undo button.

#Day-to-day workflow

The pattern that emerged from our private beta is something like:

1. You start a project with a Postgres connection. DBarn picks it up automatically from your .env.
2. While developing, you keep DBarn open in a side panel. Agents draft and run queries; you see the results live.
3. When something is off — a row that looks wrong, a column that should not be null — you fix it inline without writing the SQL yourself.
4. When you ship to production, you swap the connection string. Read-only mode kicks in by default. You sleep at night.

#What it is not

DBarn is not a BI tool. It is not a data warehouse. It is not a visual schema designer (yet — Q1 fix). It is not multi-database join. It is not optimized for tables with ten million rows (we cap row browse at 10k by default and force you to filter for larger sets).

If you need any of those, you have heavier tools available, and we are not trying to replace them. DBarn is the everyday utility — the tool you reach for when you just need to see a row and maybe nudge it.

#Try it

Open Studio v1.0.18 or later. Open any project that has a database in its .env. DBarn is in the sidebar. Connect, browse, edit. If you hit a rough edge, the feedback button at the top of every panel files straight to our backlog.