Dita Aji Pratama - Random
RSS FeedReflections from Two Different Worlds
A few years ago, I worked at a furniture company. I handled the back-end and decided to build a system using stored procedures for classic but valid reasons: performance and complete control over the database logic.
Everything was going well. Queries were fast, the system was stable, and daily reports could be processed without significant bottlenecks. But one day, a major maneuver occurred in the IT team. The project I was building was going to be handed over to a new IT team.
At first, I thought, "Okay, they'll just keep going.", But I was wrong. This new team overhauled the entire system from scratch. Not just the application code, but even the stored procedures I had written were ignored.
I was confused: "why did they do that?" "Wouldn't it be more time-saving to just keep going?" At the time, I hadn't found the answer.
Some time later, I moved to a new office. This office uses a modern technology stack with its built-in ORM framework. And this is where I was hit with a soft slap. Everything felt easier. Creating a model? Just write a few lines. Creating a query? Just .objects.filter(). Migrating a database? Run one command, and you're done. Even during the assessment test, I thought, "How come this is so easy?". Many of the manual steps I used to perform in the database were now handled automatically by the ORM.
It was at that point that I truly understood: Stored procedure developers can adapt quickly to ORM, but not vice versa.
Why?
Because stored procedure developers already understand the basic foundations. table relationships, indexes, transactions, and query optimization. ORM developers, on the other hand, are used to higher layers of abstraction. When they have to "jump" directly into procedural SQL, everything feels foreign.
And at that moment, I began to understand why the new IT team at the furniture company chose to rebuild the system from scratch. It's not that the old system was bad, but because they weren't used to how stored procedures worked.
They lived in an ORM ecosystem and switching to a legacy, procedural system was a major paradigm shift.
For those who haven't experienced them, ORM and stored procedures seem like two completely different worlds.
In the ORM world, business logic resides at the application code level. Developers simply interact with the model, and the ORM translates it into SQL.
In the stored procedure world, however, most of the business logic lives in the database where every calculation, validation, and transaction is written in procedural SQL.
ORM developers live in a clean, comfortable upstairs space. Simply calling functions like .filter() or .save(). Stored procedure developers, on the other hand, work in the underground engine room, among interconnected tables, triggers, and indexes.
I can say the reason isn't technical ability, but a difference in mindset.
ORMs foster an object-centric mindset. Data is treated as an object, with attributes and methods.
Stored procedures foster a data-centric mindset. Developers must think about how data moves and changes within the database.
Furthermore, ORMs offer a world of order: automated migrations, model validation, Git integration, and synchronous documentation.
Meanwhile, stored procedure-based systems tend to be “traditional”: manual updates, outdated documentation, and dependencies hidden within the database.
Developers who grew up with ORMs will have a hard time adapting to stored procedure-based systems, but stored procedure developers can quickly adapt to ORMs.
Many people think stored procedures are old-fashioned, and ORMs are the future. However, it's not that simple.
Stored procedures still excel in performance and control, while ORMs excel in development speed and flexibility. Both have their place.
From personal experience, I've learned that understanding both actually makes me a more well-rounded developer. I'm less fanatical about one approach. Because ultimately, what matters isn't whether to use an ORM or not, but understanding the data logic behind the systems we build.
Whether in the database or in the model, as long as we understand the thinking behind it, we'll never "lose our way" as developers.
Refleksi dari Dua Dunia yang Berbeda
Beberapa waktu yang lalu, saya sempat bekerja di sebuah perusahaan furnitur. Saya menangani bagian Back-End dan memutuskan untuk membangun sistem menggunakan stored procedure karena alasan klasik tapi valid: performa dan kontrol penuh atas logika di database.
Semuanya berjalan baik. Query cepat, sistem stabil, dan laporan harian bisa diproses tanpa bottleneck berarti. Tapi suatu hari, terjadi manuver besar di tim IT. Proyek yang saya bangun akan di-hand-over ke tim IT baru.
Awalnya saya berpikir, “Oke, mereka tinggal lanjutkan saja.” Tapi ternyata saya salah besar. Tim baru ini malah merombak ulang seluruh sistem dari awal. Bukan hanya kode aplikasinya, bahkan stored procedure yang saya tulis pun tak terpakai.
Saya sempat bingung, "kenapa mereka melakukan itu?" "Bukannya lebih hemat waktu kalau tinggal melanjutkan?" Saat itu, saya belum menemukan jawabannya.
Beberapa waktu kemudian, saya pindah ke kantor baru. Kantor ini menggunakan stack teknologi modern dengan ORM bawaan framework-nya. Dan di sinilah saya tertampar halus. Segalanya terasa lebih mudah. Membuat model? Cukup tulis beberapa baris. Buat query? Tinggal .objects.filter(). Migrasi database? Jalankan satu perintah, selesai. Bahkan saat menjalani test assessment, saya sempat merasa, “Kok gampang banget ya?” Banyak langkah manual yang biasanya saya lakukan di database kini sudah otomatis ditangani oleh ORM.
Di titik itu saya baru benar-benar paham: Developer stored procedure bisa beradaptasi cepat ke ORM, tapi tidak sebaliknya.
Kenapa?
Karena developer stored procedure sudah paham fondasi dasarnya. Relasi tabel, index, transaksi, dan optimasi query. Sementara developer ORM terbiasa dengan lapisan abstraksi tinggi. Saat mereka harus “turun” langsung ke SQL procedural, semuanya terasa asing.
Dan pada saat itulah, saya mulai memahami kenapa tim IT baru di perusahaan furnitur dulu memilih membangun ulang sistem dari awal. Bukan karena sistem lama buruk, tapi karena mereka tidak terbiasa dengan cara kerja stored procedure.
Mereka hidup di ekosistem ORM dan berpindah ke sistem lama yang procedural adalah lompatan besar dalam paradigma berpikir.
Bagi yang belum pernah mengalaminya, ORM dan stored procedure itu seperti dua dunia yang benar-benar berbeda.
Di dunia ORM, logika bisnis ada di level kode aplikasi. Developer cukup berinteraksi dengan model, ORM yang menerjemahkannya jadi SQL.
Sementara di dunia stored procedure, sebagian besar logika bisnis justru “tinggal” di dalam database di mana setiap perhitungan, validasi, dan transaksi ditulis dengan bahasa SQL procedural.
Kalau diibaratkan, developer ORM hidup di lantai atas yang bersih dan nyaman tinggal memanggil fungsi seperti .filter() atau .save(). Sedangkan developer stored procedure bekerja di ruang mesin bawah tanah, di antara tabel, trigger, dan indeks yang saling terhubung.
Saya bisa bilang penyebabnya bukan soal kemampuan teknis, tapi perbedaan cara berpikir.
ORM membentuk pola pikir object-centric. Data dianggap sebagai objek, punya atribut dan metode.
Stored procedure membentuk pola pikir data-centric. Developer harus berpikir tentang bagaimana data bergerak dan berubah di dalam database.
Selain itu, ORM menawarkan dunia yang serba rapi: migrasi otomatis, validasi model, integrasi Git, dan dokumentasi yang sinkron.
Sedangkan sistem berbasis stored procedure cenderung “tradisional”: update manual, dokumentasi sering ketinggalan, dan dependency tersembunyi di dalam database.
Developer yang tumbuh dengan ORM akan kesulitan masuk ke sistem berbasis stored procedure, tapi developer stored procedure bisa dengan cepat beradaptasi ke ORM.
Banyak orang berpikir stored procedure itu kuno, dan ORM adalah masa depan. Padahal tidak sesederhana itu.
Stored procedure tetap unggul dalam performansi dan kontrol, sementara ORM unggul dalam kecepatan pengembangan dan fleksibilitas. Keduanya punya tempat masing-masing.
Dari pengalaman pribadi, saya belajar bahwa memahami keduanya justru membuat saya jadi developer yang lebih utuh. Saya tidak terlalu fanatik pada satu pendekatan karena pada akhirnya, yang penting bukan “pakai ORM atau tidak”, tapi memahami logika data di balik sistem yang kita bangun.
Entah di database, entah di model, selama kita paham cara berpikir di baliknya, kita tidak akan pernah “kehilangan arah” sebagai developer.