The Last Wall
I built PsychoDB because I'm tired of watching the future get stuck at the database layer.
We're living through something unprecedented. For the first time in history, anyone can build software. You describe what you want, an AI writes it, and in twenty minutes you have something that works. A real app. With logic, with a UI, with intention behind it.
And then you need to store data.
And everything stops.
The deployment tax
Here's what "getting started" looks like with a modern database in 2026:
You just mass the stack for storing {"name": "Alice"}.
This is insane. We've normalized insanity. We've built an entire industry around making simple things complicated and then selling courses on how to navigate the complexity we created.
The AI just wrote your app in twenty minutes. The database setup takes longer than the app itself.
Supabase and the illusion of simplicity
I'll say what everyone who's actually shipped on Supabase knows but won't say publicly: it scales terribly for the way people actually use it.
Supabase markets itself as the "easy Postgres." But Postgres isn't easy. It's a forty-year-old row-based relational database with a query planner, a vacuum system, WAL segments, connection limits, and an entire textbook worth of indexing strategies. Putting a nice dashboard on top of that doesn't make it simple. It makes it a trap.
Here's what happens. A developer — usually someone new, often building their first real project with AI — creates a Supabase project. They store some data. It works great. The AI helped them write the queries. Everything is fast.
Then users show up.
They didn't add an index on the column they're filtering by, because nobody told them to and the AI didn't think to. They're doing SELECT * on a table with fifty columns when they need two. They've got N+1 queries because the ORM the AI generated does joins in application code. They're hitting the connection pool limit because every serverless function opens a new connection. Their RLS policies are doing a subquery on every single row.
The app loads in minutes. Literal minutes. And the data isn't even that big — maybe a few hundred thousand rows. A rounding error.
"This isn't the developer's fault. This is a design problem. You gave someone a Formula 1 car and told them it's a bicycle. When they crash, you blame them for not reading the manual."
The wrong abstraction won
Relational databases won the 1980s. They were the right tool when humans wrote every query by hand, when data integrity meant everything because a single typo could corrupt your books, when you needed to join six tables to generate a quarterly report.
That world is gone.
In the age of AI-generated applications, nobody is hand-writing SQL. Nobody is staring at rows in a database admin panel. Nobody is designing entity-relationship diagrams on a whiteboard. The AI generates the code, the code talks to the database, the user sees the interface. The data underneath is an implementation detail that no human ever looks at.
So why are we still paying the tax for a storage model designed around human readability?
All of this overhead exists to make relational databases work. And none of it serves the actual goal, which is: store this thing, get it back later, do it fast.
Row-based databases are overhead engines. They spend more cycles managing themselves than serving your application. And we've just... accepted this. We've built our entire industry on top of it and convinced ourselves it's necessary.
It's not.
What if the database was just a URL?
PsychoDB is a key-value store. You PUT data in, you GET data out. Every stored value is a URL. That's the entire mental model.
You store something and it's live. Right now. At a URL you can paste into a browser.
curl -X PUT https://psychodb.com/YOUR_KEY/kv/posts/hello \
-d '{"title": "Hello world"}'
Done. It's stored. It's accessible. It's fast. Move on. Build the next thing.
Every app is an API. For free.
Most apps are walled gardens. You get a UI and, if you're lucky, a half-API behind an enterprise tier. The vendor owns the only door.
Apps built on PsychoDB invert this. The storage layer is the API. The same URLs the app reads and writes are the URLs anyone else can read and write. Nothing to design, document, version, or gate.
That matters now more than ever: LLMs drive apps through APIs the way people drive them through UIs. A PsychoDB app exposes every object at a URL the moment it exists — so Claude is a first-class user on day one, side by side with the human clicking around.
The API isn't on the roadmap. It's done the moment the app works.
Psychotically resilient
Here's what I mean when I say PsychoDB doesn't have the pitfalls.
In Supabase, if an inexperienced developer dumps a million records into a table with no indexes and does a filtered query, the database scans every single row. Linear scan. The app dies. This is by design — Postgres is powerful, but power without guardrails is a footgun.
In PsychoDB, your data lives in namespaces. Each namespace is its own bucket. If you have a million keys in a namespace and you list them, you get a paginated cursor response. There's no full table scan. There's no query that can accidentally touch every record. The worst case is already bounded.
There's no webserver in between. No application runtime interpreting your request. Straight C and Lua accessing memory directly. A GET request doesn't parse SQL, doesn't plan a query, doesn't check permissions on every row, doesn't join tables, doesn't aggregate results. It looks up a key and returns the data. Microseconds.
You can't design yourself into a corner. An AI generating PsychoDB calls can't accidentally create a query that brings down your app. The API surface is so small that there's nowhere to hide a performance cliff.
Four operations. All O(log n) or better. All paginated by default. All fast regardless of how much data you have.
That's not a limitation. That's a feature. The constraint is the protection.
Why I'm building this
I want to be the person who breaks down the last wall.
AI has democratized code. Deployment is getting easier every year. Hosting is a solved problem. CDNs are commoditized. But the database — the database is still a gatekeeper. It's still the step where you need to "know what you're doing." It's still where beginners get punished and projects die.
Every abandoned side project that worked perfectly in a demo but couldn't figure out the database layer.
Every AI-generated app that was brilliant for twenty minutes until the developer hit "how do I persist this."
Every startup idea that died in the gap between prototype and production because Postgres migrations felt like a foreign language.
That's the wall. And it shouldn't exist.
Psychotically fast.
Psychotically simple.
Psychotically usable.
That's not a tagline. That's a design constraint.
Psychotically Fast
Bare metal. No webservers, no containers, no Lambda spin-up. Straight C and Lua reading directly from memory. No cold starts. Microseconds, not milliseconds.
Psychotically Simple
Four API operations. No SDK required. No config files. No environment variables. No schema. No migration. curl is your client. A URL is your query.
Psychotically Usable
Paste one block of text into your AI and it knows everything about PsychoDB. Install one MCP server and your AI can read and write natively. An inexperienced developer can't accidentally build something slow. The API won't let them. The worst-case performance is still fast.
I don't want to build another database company. I want to make databases disappear. I want the storage layer to be so invisible, so fast, so obvious that nobody ever thinks about it again.
You should be thinking about what you're building. Not where you're storing it.