AI Database Architect

Turn a prompt, a document, or an existing database into a live AWS backend — relational schema, CRUD APIs, and an admin dashboard — in seconds.

💡 Inspiration

Every project starts the same way: someone has an idea — or a messy spreadsheet — and then loses days building plumbing. Designing tables, wiring foreign keys, writing CRUD endpoints, and standing up an admin UI before any real work begins.

We wanted to collapse that gap — not "generate some boilerplate," but actually stand up a working, data-backed backend from whatever the user already has: a sentence, a CSV, a legacy database. The key insight: most people don't have a schema, they have data shaped like a spreadsheet, and the hard, valuable part is turning that flat data into a correct relational model.

🚀 What it does

Three ways in, one production-ready backend out:

Prompt → Backend — Describe a domain ("a veterinary clinic with owners, pets, appointments, prescriptions…") and an LLM on AWS Bedrock infers entities, relationships, and validation rules.
Document → Backend — Upload a CSV, Excel (multi-sheet), or PDF. It performs intelligent relational modeling: a flat attendance sheet becomes Students + Faculty + Attendance instead of one dumb table, and the actual rows are loaded into the database.
Existing Database Import — Point it at a live PostgreSQL or MySQL database; it introspects the schema, migrates it to Amazon Aurora PostgreSQL, copies the data, and suggests improvements.

For every path it then:

generates an ordered SQL migration and runs a round-trip verification gate (parse the DDL back into a model and structurally diff it) so a lossy schema can never deploy;
deploys each generation into its own isolated schema on Amazon Aurora PostgreSQL (Serverless v2);
generates a full CRUD REST API and an admin dashboard that read and write the real database;
shows the detected structure as an ER diagram and lists the generated endpoints with copy-paste curl.

🛠️ How we built it

The core is a dialect-independent data-model IR with a strict "model first, generate second" discipline. Everything is a pure projection of that IR:

Modeling Engine — the prompt path uses AWS Bedrock (Amazon Nova); the document path uses a deterministic, LLM-free relational decomposition that detects repeating field groups by functional-dependency clustering and extracts them into their own entities.
Schema Generator — projects the IR to ordered Aurora PostgreSQL DDL (topologically sorted, with foreign-key indexes and constraints).
Round-Trip Verifier — a focused DDL parser that reconstructs the IR and diffs it against the source, as a fail-closed deploy gate.
Provisioner — a transactional migration runner over node-postgres, deploying one isolated gen_<id> schema per generation to Aurora.
API + Dashboard generators, an Auth service, and an Orchestrator state machine that drives the whole pipeline with progress reporting and timeouts.

We developed it spec-first with Kiro — formal requirements, a design doc, and a task list — and validated correctness with property-based testing (fast-check): 46 correctness properties across 211 tests. The frontend is a Next.js app that consumes the engine as a compiled library and talks to a live Aurora cluster.

📚 What we learned

Deterministic decomposition beats guessing. A rule-based decomposition of flat data was more reliable, explainable, and testable than asking an LLM to model a spreadsheet.
Property-based testing pays off. Encoding invariants — one primary key per entity, supported types, referential closure, round-trip fidelity — caught real bugs that example-based tests missed.
A round-trip verifier is a powerful safety net. Parsing your own generated DDL back into the model and diffing it makes "we never deploy a lossy schema" a guarantee, not a hope.

🧗 Challenges we faced

Loading real data, fast. Our first version inserted rows one at a time over the network to the database — a 23,000-row CSV hung for minutes. Switching to batched multi-row inserts brought it down to ~8 seconds.
Schema isolation. Repeated generations collided on table names, so we gave each generation its own gen_<id> schema on the Aurora cluster.
PDF parsing under a bundler. The PDF engine (pdf-parse v2 / pdfjs-dist) had to be marked an external server package so it resolved at runtime instead of breaking the build.
Honest persistence. Making the dashboard truly database-backed — live CRUD against Aurora, including auto-assigning integer primary keys lost during migration — instead of an in-memory illusion.
Type fidelity across sources. Coercing CSV strings, Excel natives, and MySQL/Postgres types into one consistent model so constraints and seeding behave the same everywhere.