Skip to content
Human Written
IMPORTANT

As you may notice, this page and pretty much the entire website were obviously created with the help of AI. I wonder how you could tell? Was it a big "Written With Claude" badge on every page? I moved it to the top now (with the help of AI of course) to make it even more obvious. There are a few blogposts that were written by me manually, the old-fashioned way, I hope there will be more in the future, and those have a similar "Human Written" badge. This project (not the website), on the other hand, is a very, very different story. It took me more than two years of painstaking and unpaid work in my own free time. A story that, hopefully, I will tell someday. But meanwhile, what would you like me to do? To create a complex documentation website with a bunch of highly technical articles with the help of AI and fake it, to give you an illusion that I also did that manually? Like the half of itnernet is doing at this point? How does that makes any sense? Is that even fair to you? Or maybe to create this website manually, the old-fashioned way, just for you? While working a paid job for a salary, most of you wouldn't even get up in the morning. Would you like me to sing you a song while we're at it? For your personal entertainment? Seriously, get a grip. Do you find this information less valuable because of the way this website was created? I give my best to fix it to keep the information as accurate as possible, and I think it is very accurate at this point. If you find some mistakes, inaccurancies or problems, there is a comment section at the bottom of every page, which I also made with the help of the AI. And I woould very much appreciate if you leave your feedback there. Look, I'm just a guy who likes SQL, that's all. If you don't approve of how this website was constructed and the use of AI tools, I suggest closing this page and never wever coming back. And good riddance. And I would ban your access if I could know how. Thank you for your attention to this matter.

The Power of Simplicity

March 2026 · ArchitectureOpinion


The standard data access pattern for modern, business, data-driven applications is this:

UI (browser client) → Fetch (Browser API calls) → Server Endpoint (Controller) → Service LayerRepositoryORMSQL (Automatic with ORM) → RDBMS

We do this so that we can mock the Repository and test logic in the Service. The problem with this approach is that once you realize how trivial it is to wire up database-aware tests - you can call them what you like, integration tests, database tests, whatever - once you realize that, you also realize you can collapse at least two layers:

UI (browser client) → Fetch (Browser API calls) → Server Endpoint (Controller) → ORMSQL (Automatic with ORM) → RDBMS

This is much, much simpler. But then, as you become proficient with SQL and you realize you can do things that ORM can't generate, and in many cases faster and more efficient, you realize this can be even simpler:

UI (browser client) → Fetch (Browser API calls) → Server Endpoint (Controller) → SQLRDBMS

And then you realize SQL actually has a rich type system - at least something mature and advanced as PostgreSQL does - and that type system can be used as a contract, and that Controller code is just boring glue code that can and should be automated:

UI (browser client) → Fetch (Browser API calls) → Automatic Server Endpoint (Controller) → SQLRDBMS

But why stop there? If the controller can be automated, why not generate those Fetch calls as well? And that SQL can be stored in the RDBMS. Finally, this is what we have, basically:

UIRDBMS

System Diagram

Now, if we all start doing software architecture like that, imagine how many tokens and energy we could save... That is what I call the energy efficiency. In a time of looming energy crisis, we could probably power a small country with the power of simplicity.


If you want to learn how to do this with PostgreSQL, check out the Quick Start Guide or dive into the Tutorials.

Comments