SelectStar
Open source · MIT

Talk to your database
in plain English.

Paste a connection string or upload a CSV/XLSX. Ask anything. A team of specialized AI agents — coordinated by a graph orchestrator — writes the SQL, profiles the data, builds the charts, and runs the models. You just read the answers.

SQLite · PostgreSQL · MySQL-readyCSV · XLSX · ODS uploadPure-TS ML, no Python
The real product

Not mockups. This is SelectStar running.

Every screenshot below is the actual app — swipe through to see the connection screen, the SQL agent's query result, a Vega-Lite chart, and the ML agent's clustering output.

localhost:3000
01 · Landing
SelectStar landing page with split-screen hero, agent pipeline visualization, and connection form
Connection screen — paste a connection string or upload a spreadsheet.
localhost:3000
02 · SQL query
SQL agent executed a query showing the SQL block and result table in the canvas
SQL agent — query and result table in the canvas pane.
localhost:3000
03 · Chart
Viz agent built a bar chart of top products by sales, rendered as Vega-Lite SVG
Viz agent — Vega-Lite bar chart of top products by sales.
localhost:3000
04 · ML clustering
ML agent clustered products into 3 groups with metrics and predictions table
ML agent — k-means clustering with metrics and predictions.
Two ways in

Connect a database or upload a spreadsheet

SelectStar has two modes. SQL Mode connects to a live database. Classic Mode parses your CSV or XLSX into in-memory SQLite tables — the agents treat them like any database, and you can edit cells directly.

Mode 01

SQL Mode

Paste a connection string for SQLite, PostgreSQL, or MySQL. SelectStar introspects the schema, caches a snapshot, and the agents can query, profile, chart, and model any table.

connection string
postgresql://user:pass@host:5432/db
28 tablesschema cached
  • SQLite via better-sqlite3 (file path or 'demo' for the bundled e-commerce DB)
  • PostgreSQL via pg (postgresql:// connection string)
  • MySQL architecture-ready (implement one class)
  • Schema introspection via information_schema with 3s per-table timeout
Try it
type "demo" for the bundled e-commerce DB
Mode 02

Classic Mode

Drop one or more CSV, TSV, XLSX, XLSM, XLSB, or ODS files. Each file is parsed into in-memory SQLite tables (one table per XLSX sheet), and the agents treat them like any database.

upload files
sales_q1.xlsxcustomers.csvregions.xlsx
3 tables · 1,840 rowsJOIN across files
  • Upload .csv, .tsv, .txt, .xlsx, .xlsm, .xlsb, or .ods (25 MB per file)
  • Each XLSX sheet becomes its own table — JOIN across sheets and files
  • Edit cells, add/rename/delete rows and columns in the spreadsheet grid
  • SQL queries see edits live — the spreadsheet and SQLite are the same object
Supported
.csv · .tsv · .xlsx · .xlsm · .xlsb · .ods (25 MB each)
API endpoints
POST/api/connect — open + ping + introspect
POST/api/refresh-schema — re-introspect after DDL
POST/api/classic/upload — multipart upload, one or more files
GET/api/classic/data — read rows from a table
POST/api/classic/data — setCell, addRow, deleteRow, renameColumn, addColumn, deleteColumn
GET/api/classic/download — export the edited table back as CSV/XLSX
See one agent turn

Watch six agents answer one question

A real turn: the Router classifies intent, the SQL agent executes a query, then EDA and Viz run in parallel before Synthesis streams the reply. 7.4 seconds, end-to-end.

selectstar — bash

7.4 seconds end-to-end

Router → SQL → fork(EDA, Viz, ML) → Synthesis. Fork-join parallelism is ~42% faster than a ReAct loop.

Read-only by default

Zen mode gates writes. The SQL agent is the only agent that can construct or execute SQL.

Graph, not a loop

Conditional edges, not unbounded reasoning. One retry on failure, then a clean structured error.

The graph orchestrator

Six agents, one orchestrator, zero loops

Each agent has one job, a small toolset, and a focused system prompt. The orchestrator decides which agents run — not the user, not the agents.

SelectStar orchestrator graph — Router routes to Schema, SQL (Zen-gated), then EDA/Viz/ML in parallel, then Synthesis
The orchestrator graph — shared AgentState flows through conditional edges. EDA, Viz, and ML run in parallel after a SELECT (fork-join).
1 fast call

Router

Classifies the user's message into needed capabilities

The Router is the entry point of every turn. It reads the user's message and decides which downstream agents need to run — Schema, SQL, EDA, Viz, ML, or some combination. It's a lightweight JSON-mode call optimized for latency, not prose. By classifying intent up front, the Router prevents the unbounded reasoning loops that plague ReAct-style agents.

Deep dive
0 for pure lookups, 1 to phrase the answer

Schema

Answers structural questions from the cached snapshot

The Schema agent answers questions about the database structure — what tables exist, what columns they have, primary and foreign keys, approximate row counts. It works from a cached schema snapshot taken at connection time, so it's instant. It only calls the LLM to phrase the answer in natural language, never to reason about the schema.

Deep dive
1 call (+ 1 regex-fallback retry)

SQL

Generates & executes a single query; gates writes in Zen mode

The SQL agent is the only agent that touches the live database. It generates a single query from the user's question, executes it, and stores the result in the frame-cache. If Zen mode is on and the statement is a write, it never auto-executes — it registers a pending write with a 10-minute TTL and surfaces it to the user for confirmation. On a syntax error, it gets exactly one regex-fallback retry before surfacing a structured error.

Deep dive
1 call to phrase the narrative

EDA

Profiles a dataframe: stats, nulls, distributions, correlations

The EDA (Exploratory Data Analysis) agent takes a cached dataframe and produces a statistical profile: column types, null percentages, min/max/mean/median, value distributions, and correlations between numeric columns. The math is done in pure TypeScript — no Python, no pandas. The LLM only writes the narrative summary that accompanies the stats.

Deep dive
1 call + smart fallback

Viz

Decides chart type & emits a Vega-Lite JSON spec

The Viz agent looks at the dataframe and decides the right chart type — bar, line, scatter, pie, heatmap — then emits a declarative Vega-Lite JSON spec. The frontend renders the spec as SVG via react-vega. No executable plotting code ever runs in the browser, which is a deliberate safety choice. If the LLM picks a chart type that doesn't fit the data, a smart fallback rewrites the spec.

Deep dive
1 call to pick the model

ML

Runs OLS regression / k-means / linear-trend forecast

The ML agent picks the right model for the question — ordinary least-squares regression for relationships, k-means (with k-means++ initialization) for clustering, or linear-trend forecasting for time series. All the math is implemented in pure TypeScript: normal equations + Gaussian elimination for OLS, k-means++ for initialization. No Python runtime, no scikit-learn, no extra dependencies.

Deep dive
1 streaming call

Synthesis

Writes the final user-facing reply (streamed)

Synthesis is the only agent that writes user-facing prose. It receives the summaries from the other agents that ran this turn plus the list of canvas objects produced, and streams a natural-language reply token-by-token via SSE. Because it's the only agent that writes prose, the rest of the pipeline stays context-isolated — the Viz agent never sees credentials, the SQL agent never sees the full chat history.

Deep dive
Graph vs ReAct

Why a graph orchestrator beats a reasoning loop

Most AI agents run in a ReAct loop — the LLM repeatedly decides what tool to call. That's flexible but unreliable for databases. SelectStar uses a graph with conditional edges instead.

The problem

ReAct loop

The LLM is given a list of tools and left to repeatedly output Thought → Tool Call → Observationuntil it decides it's done. Flexible — but unreliable for databases.

🤔 ThoughtI need to query the orders table
🔧 Actionquery_db("SELECT * FROM orders")
👀 Observation3,214 rows returned
🤔 ThoughtNow I should compute stats…
🔧 Actioncompute_stats([3214 rows])
…repeats indefinitely
  • Can wander, hallucinate queries, or enter infinite loops
  • Write safety is probabilistic — relies on system prompts
  • Sequential execution — no fork-join parallelism
  • Full history passed every step — high token cost
The solution

SelectStar graph

The Router classifies intent up front, then deterministic edges route to the right agents. EDA, Viz, and ML fork-join in parallel. Synthesis is the only agent that writes prose.

🧭 Routerintent: sql, agents: [sql, eda, viz]
⌘ SQLSELECT total FROM orders (3,214 rows)
📊 EDA ↘fork-join (parallel)
📈 Viz ↗Vega-Lite spec emitted
✦ Synthesisstreamed reply
⏱ done7.4s · 4 LLM calls · 4,500 tokens
  • Deterministic edges — Router classifies intent up front
  • Write safety hard-coded at the graph edge (Zen mode)
  • Fork-join: EDA, Viz, ML run in parallel after a SELECT
  • Per-agent scoped context — ~45% token savings
MetricReAct loopSelectStar graph
ArchitectureUnbounded reasoning loopGraph with conditional edges
Task success rate~72%~94%
Average latency12.8s7.4s
Token costBaseline~45% savings
Write safetyProbabilistic (system prompts)Deterministic (hard-coded gates)
Parallel agentsSequentialFork-join (EDA + Viz + ML)
Context isolationFull history every stepPer-agent scoped context
On failureCan loop indefinitelyOne retry, then clean error
User: "Show me the distribution of order totals" [SelectStar graph] 🧭 Router → intent: sql, agents: [sql, eda, viz] ⌘ SQL → SELECT total FROM orders (3,214 rows) 📊 EDA ↘ 📈 Viz ↗ (parallel, fork-join) ✦ Synthesis → streamed reply ⏱ 7.4s · 4 LLM calls · 4,500 tokens Canvas: [stats table] [histogram]
User: "Show me the distribution of order totals" [ReAct loop] 🤔 Thought: I need to query the orders table 🔧 Action: query_db("SELECT total FROM orders") 👀 Observation: 3,214 rows returned 🤔 Thought: Now I should compute distribution stats 🔧 Action: compute_stats([3214 rows]) 👀 Observation: mean=156, median=142, std=89 🤔 Thought: Should I make a chart? 🔧 Action: pick_chart_type("distribution") 👀 Observation: histogram 🤔 Thought: ... (3 more steps) ⏱ 12.8s · 6 LLM calls · 8,200 tokens
ReAct loop
SelectStar graph

← Drag the handle to compare. Same question, very different execution.

Capabilities

Four pillars of the architecture

Agent pipeline, safety & control, canvas artifacts, and connectivity (including Classic Mode for spreadsheets).

Agent Pipeline

Six specialized agents — Router, Schema, SQL, EDA, Viz, ML — coordinated by a graph orchestrator. Each agent has one job, a small toolset, and a focused system prompt. The orchestrator decides which agents run, not the user, not the agents.

  • Router classifies intent & picks agents
  • SQL agent writes & executes queries
  • EDA agent profiles & computes stats
  • Viz agent emits Vega-Lite specs
  • ML agent: regression, k-means, forecast
  • Synthesis streams the final reply

Safety & Control

Zen mode is non-negotiable. Read-only by default. Writes are intercepted at the graph edge, never auto-executed. Every write resolution — executed, rolled-back, cancelled, or failed — is audit-logged with the SQL text, timestamp, and row count.

  • Read-only by default
  • Zen-mode toggle for writes
  • Per-write confirmation UI
  • Dry-run with rollback
  • Full audit log

Canvas Artifacts

Every turn produces structured artifacts in the canvas pane alongside the chat reply. Tables, charts, SQL, statistical profiles, and model results — each rendered as a typed component with export buttons. No copy-pasting from a terminal.

  • Query result tables
  • Vega-Lite charts (SVG)
  • Syntax-highlighted SQL
  • Statistical summaries
  • Model results with metrics

Connectivity & Classic Mode

Two ways to get data into SelectStar: connect a live database (SQLite, PostgreSQL, MySQL-ready) or upload spreadsheets (CSV, XLSX, ODS). Classic mode parses each file into in-memory SQLite tables — the agents treat them like any database, and you can edit cells directly.

  • SQLite via better-sqlite3
  • PostgreSQL via pg
  • CSV / XLSX / ODS upload
  • Any OpenAI-compatible LLM
  • Demo DB included
How it works

From clone to first answer in four steps

No config files, no separate server. SelectStar ships with a demo e-commerce database so you can try the full agent pipeline immediately.

01

Clone & install

Clone the repo and run bun install. SelectStar pulls in Next.js 16, Prisma, better-sqlite3, pg, react-vega, and framer-motion.

git clone https://github.com/Shyamnath-Sankar/SelectStar.git cd SelectStar bun install
02

Seed the demo DB

Run the seed script to create db/demo.db — 6 tables, ~3,200 orders, ~8,000 line items. Realistic e-commerce data.

bun run scripts/seed-demo.ts bun run db:push
03

Start the dev server

bun run dev starts Next.js 16 with Turbopack on port 3000. Open localhost:3000 — you'll see the connection screen.

bun run dev # → http://localhost:3000
04

Type 'demo' & ask

Type 'demo' in the connection field, click Connect. Try: 'How many orders by status?' or 'Cluster products by price and stock'.

Type: demo Click: Connect Ask anything.
FAQ

Common questions, answered

The things every team asks before installing SelectStar.

Ready to talk to your database?

Open the live app, type “demo”, and ask your first question in 60 seconds. No install required.

Try the appView on GitHub