What if the database were the network?

I rode home from work last Tuesday thinking about Pinata, which is a strange thing to think about on a motorbike. I had not touched Web3 in a while. I went through a phase of it, built a few things, pinned a lot of files to Pinata, and then lost interest the way you lose interest in anything that stops being a puzzle. That was maybe a year back.

Pinata pins files to IPFS. That is the whole product. You hand it a file, it hands you back a CID, and it keeps a copy on a machine so the file stays reachable. I used it enough to know its rough edges and then stopped caring.

And then on this one ride home, the obvious question arrived late: wait. If Pinata stores my file and gives me back an address, what is the difference between that and a database? A database stores rows and gives you back a key. Pinata stores blobs and gives you back a CID. The shapes are almost the same.

That kept me occupied the whole way home. By the time I parked I had a full idea in my head, which is the dangerous kind, so I did the reasonable thing and argued with a chatbot about it for two hours.

The idea, as it arrived

Build a Web3 database. Instead of Postgres on a server you rent, every row lives on IPFS. The CID is the primary key. Reads hit a gateway, writes pin a new object, and the network handles replication for you. No server to patch, no single machine holding the data, no company that can turn your database off.

The appeal is not subtle. A normal database is a machine you own and have to keep alive. An IPFS-backed store is a network you join and mostly forget about. If the whole thing is just addresses pointing at content, then the storage layer stops being your problem, which is most of what running a database actually is.

Then I made the mistake of asking whether it actually works.

What the chatbot said, and where it was right

I described the idea and asked for the problems. It gave me a clean list. Personal security, because a database you can read by address is a database anyone can read by address. Infrastructure, because the parts that make IPFS good at storage are the parts that make it bad as a database. Speed, because a content-addressed network is not built for the query patterns a database needs. I argued with some of it and conceded the rest.

The speed point is the one that actually killed the idea. A database does more than store. It indexes, it filters, it joins, it sorts, and it answers questions that were never anticipated when the data went in. IPFS does none of that. It stores a blob under an address and returns the blob when you ask for the address. If you want to find every row where the status is pending, you have to fetch all the blobs and look, which is the thing databases exist to prevent.

I sat with that for a while. The idea did not survive contact with it, at least not in the form I had on the motorbike. But the argument was productive, because it turned a vague feeling into a specific list of reasons, and a specific reason can be worked on. A vague feeling cannot.

The privacy problem is the interesting one

Security was the point I pushed back on hardest, and it is worth writing down because I was wrong and the correction mattered.

I argued that content addressing is secure. The address is a hash of the content, so if someone changes the file, the address changes, and you cannot be served something that pretends to be something else. That is true, and it is genuinely nice. It is also completely orthogonal to the question of who is allowed to read it.

A CID is a hash. If I know the hash, I can fetch the file from any node that has it. There is no login in that flow. The address being tamper-proof tells you the file is intact. It tells you nothing about whether you should have it. For a public image that is fine and good. For a database with a users table it is a disaster, and the fix is not on the network. It is on you.

What you actually do is encrypt before you pin. The network stores ciphertext, the key never leaves your app, and the CID now points at a blob nobody can read without the key. That works. It also means the network stops knowing anything about your data, which is both the point and a real cost, because now every feature that needs to read or filter or aggregate has to happen after decryption, in your code, without the network's help. The privacy is achievable. It just moves the work back to you, which is a pattern.

The database was the easy part

The more I looked at it, the more the original idea felt backwards. I had been thinking of storage as most of a database, because storage is the part that is easy to see. A database is a box you put data in and a thing that keeps it there.

But storage is the easy part. Any disk does storage. What makes a database a database is everything you build on top to avoid reading all of your data every time you ask a question. The index. The query planner. The transaction that either lands or does not. The join that pulls two tables together without you writing the loop. None of that is on the network, and none of it moves to the network, because it has nothing to do with where the bytes live. It has to do with how you find them again.

You can build a database-shaped thing on IPFS. Add an index, add a query layer, add an access control layer, add a cache so the slow reads do not kill you. Every one of those pieces is buildable. But when you are done, you have a normal database with a network in the middle and a lot of extra steps, and the network did not remove any of the hard parts. It only changed where the bytes sit.

That was the real answer to the question from the motorbike. The question was whether Pinata and a database are the same shape. They share one shape, the one where you put something in and get a key back. They do not share the shape that matters, the one where you ask a question the data was not designed to answer. Pinata never had that shape, and it was not hiding it. I just wanted the shapes to match badly enough that I stopped looking.

The idea is dead and I know why now, at least well enough to say it out loud. The mistake was thinking storage is most of a database. Storage is the easy part. The hard part is everything you do to data to avoid reading all of it, and that part does not move to a network. You can build a database-shaped thing on IPFS if you add an index, and a query layer, and an access control layer, and a cache. At that point you have built a normal database with extra steps and a network in the middle, which is a fine thing to build and not the thing I thought I was building.

The other half of the evening, the part about replacing AWS with a network, is a different idea and a better one. I will write that one separately, because it deserves more room than I can give it here and it did not fall apart the way this one did.

What I got most wrong was the mood. I had the idea on a motorbike in ten minutes and assumed the ten minutes meant something. The ten minutes meant I noticed two things share a shape. It did not mean the shape held, and it took a chat and an evening of reading to find out that it did not. The idea was one sentence. The reasons it fails are the actual thing I got out of it, and unlike the idea, they are true.