While Building KalamDB, I Started Questioning Why We Still Need So Much Backend Code

A few years ago, if someone told me that an application could work without most of its backend code, I probably would have disagreed.

Yet while building KalamDB, I slowly found myself questioning many assumptions that we take for granted when building software.

Ironically, that wasn't the original goal.

I didn't start KalamDB to reinvent application architecture.

I started it because I was frustrated with something much simpler.

I wanted a database where each user owns their data.

Not logically.

Physically.

Instead of storing millions of users inside the same giant table and constantly filtering by user_id, I wanted each user to have their own isolated storage and their own tables including his own files and folders.

That immediately solved several problems.

Security became simpler.

Privacy became simpler.

GDPR-style data ownership became simpler.

Real-time subscriptions became simpler.
Even adding an offline support for the apps seems way simpler.

And once I started building around that idea, something unexpected happened.

I realized that most of the backend code I was writing wasn't actually business logic.

It was plumbing.

The frontend would send a request.

The backend would receive it.

The backend would query the database.

The backend would transform the result.

The backend would send it back to the frontend.

Again and again.

The backend was often acting as a messenger between the application and the database.

That made me wonder:

What if the database already knows which user is connected?

What if the database already understands permissions?

What if the database can expose SQL safely?

What if the database can push changes directly to the user?

Do we still need the same amount of backend code?

Historically, every generation of software tried to remove a layer of complexity.

We started with technologies like SOAP where everything was verbose and heavily structured.

Then REST became the dominant model because it was simpler and easier to work with.

Later GraphQL appeared because developers became tired of creating endless API endpoints.

Each step reduced the amount of glue code developers needed to write.

But even GraphQL still assumes there is a backend sitting between the application and the data.

While building KalamDB, I started wondering whether the next step is removing much of that layer entirely.

If a user can only access their own tables, and if the database understands identity, permissions, subscriptions, and storage isolation, then many common application flows become surprisingly simple.

Instead of:

App → Backend → Database → Backend → App

the flow becomes:

App → Database

and

Database → App

through real-time subscriptions.

The database stops being passive storage.

It becomes an active participant in the application.

This becomes even more interesting when AI agents enter the picture.

Today's AI applications often need access to many different tools:

REST APIs.

Caches.

Message queues.

Search systems.

Event systems.

Databases.

The result is a growing collection of integrations and tool calls.

But what if most of a user's data already lives inside a database that supports SQL, subscriptions, permissions, and history?

Suddenly the AI agent's interface becomes much simpler.

Instead of learning dozens of APIs, it can simply query and subscribe.

I don't believe every backend will disappear.

There will always be business logic, integrations, payment systems, workflows, and services that belong outside the database.

But I do believe many applications are carrying far more backend code than they actually need.

Building KalamDB changed the way I think about software.

I originally wanted a better database for user-isolated data and real-time applications.

What I found instead was a different way to think about connectivity itself.

Maybe the future isn't about creating more layers between users and their data.

Maybe it's about removing the unnecessary ones.

And that's the direction I'm exploring with KalamDB.