You build a small AI thing. A weekend tool, a side project, a micro-app. Then someone asks where the data lives, and suddenly you are shopping for a database like you are buying a wedding suit for a coffee date.
Ariel’s take: start as small as possible, then upgrade only when the project actually screams for it. This video is a ladder of data stores, from a bare text file up to a managed cloud backend, plus the real talk on secrets, GDPR, and when “simple” becomes stupid.
The ladder: from text to cloud
Each step up adds power, but also adds things you have to install, secure, pay for, or explain to your future self.
1. Plain text, Markdown, CSV
The absolute minimum. A txt, md, or csv file is just data you can read with your eyes and edit with any editor. Ariel calls this the first thing to try when you are still proving the idea. It is not a database in any real sense, but for tiny apps it is often enough — especially when the AI is doing the heavy lifting and you only need a list, a log, or a simple table.
CSV in particular is a poor man’s Excel: rows, commas, done.
2. JSON with a schema
JSON files let you store objects instead of flat rows. The danger is that every object can look different from the next, so after a while your data becomes a jungle. Ariel’s fix: add a schema. Write down what fields must exist, what type they should be, and what is required. Suddenly your JSON file gets most of the discipline of a table without the database server.
It is still just a text file, so it is easy to read, version, and move around. The schema is the guardrail that keeps it honest.
3. SQLite
When you need real database behavior — queries, relations, indexes, transactions — but you do not want a server, SQLite is the sweet spot. It is a single file, has zero install ceremony, and every AI coding assistant on earth knows how to use it.
Ariel flat-out recommends SQLite for almost every small app he builds with AI. It behaves like a database, it is free, and it deploys by copying one file. The only thing lighter is a text file, and the gap is smaller than most people think.
4. Local SQL server (Postgres, MySQL, SQL Server)
If SQLite is a single file, a real SQL server is a piece of software you install, run, secure, back up, and patch. It is more powerful and scales further, but for a small project it is usually overkill. You now have ports, drivers, users, permissions, and a process that can break while you are sleeping.
Ariel puts this one level above SQLite, not because it is bad, but because it carries weight.
5. Supabase (managed backend)
At the top of the ladder sits Supabase: Postgres in the cloud with authentication, APIs, and scaling handled for you. It is the right choice when you want someone else to own the database ops, the auth layer, and the backups. It is also the heaviest option in terms of setup, cost, and lock-in.
The point of the ladder is not to worship any single rung. The point is to pick the lowest rung that solves your actual problem today.
Secrets are not part of the database
Ariel makes a hard separation: the data store holds data. Secrets — API keys, passwords, tokens — live somewhere else. Usually that means an .env file or another protected file outside the project repo, with tighter permissions on the server.
He also pushes back on the fear that giving an AI assistant a secret means the world ends. His practical take: if you are not Microsoft and the secret is not your bank password, letting a local agent use a key to install Zoom is a manageable risk. Claude will still lecture you about it, though.
GDPR, cookies, and not overthinking it
A viewer asks about storing Google IDs and game progress. Ariel’s answer: if you only keep what you are supposed to keep — a user identifier and app-specific progress — you are not building a surveillance machine. The browser cookie just lets the user continue where they left off. Do not store more than you need, and do not turn a login convenience into a privacy panic.
🔥 Roast Corner
Let us roast the people who reach for Postgres on day one because they “might scale.” You will not scale. You will build three features, get bored, and move to the next shiny idea. Meanwhile you spent a weekend configuring a server that a text file could have replaced.
Supabase is not a flex. It is a job you outsource to a company. If your app has one user and a half-dozen tables, you are paying rent for a mansion you do not live in.
And the JSON-without-a-schema crowd? You are not “move fast and break things.” You are just making tomorrow-you play detective in a file where every object is a special snowflake. Write the schema. It takes five minutes and saves five hours.
🤖 AI for Humans
The real reason this matters for AI-assisted coding is that models are trained on mountains of SQLite, JSON, and plain-text examples. They can write the code, debug the queries, and refactor the schema in seconds. The simpler your storage layer, the more likely the AI gets it right on the first try.
So here is the human translation:
- If the AI can describe your data in a single paragraph, try a text file or CSV.
- If the AI starts talking about objects and validation, use JSON with a schema.
- If the AI starts joining things, filtering, or counting, upgrade to SQLite.
- If the AI starts asking about users, auth, and cloud hosting, consider Supabase.
Do not let the database decision become a religion. Let it be a volume knob. Start quiet, turn it up only when the noise gets real.
💬 Comments