---
title: "ORM mi, Native SQL mi?"
description: "ORM bizi tembelleştiriyor mu yoksa gerçekten koruyor mu? İki yaklaşımın güvenlik, okunabilirlik ve performans dengesi."
url: https://sade.dev/tr/journal/orm-mu-native-sql-mi/
lang: tr
author: "Muhammet Şafak"
published: 2026-09-12
updated: 2026-09-13
section: Journal
tags: ["database","orm","sql","opinion"]
---

# ORM mi, Native SQL mi?

> ORM bizi tembelleştiriyor mu yoksa gerçekten koruyor mu? İki yaklaşımın güvenlik, okunabilirlik ve performans dengesi.

Bir yönetim panelinin tek bir sayfası 1.400 sorgu atıyordu. Sebep ekranda görünmüyordu: bir döngü içinde masum görünen `$order->customer->name` çağrısı, her sipariş için ayrı bir sorgu açıyordu. ORM aslında hiçbir şeyi gizlememişti — sadece geliştiricinin hangi sorgunun çalıştığını düşünmeyi bırakmasına izin vermişti.

ORM bizi tembelleştiriyor mu, yoksa koruyor mu? Cevap: ikisi de — ve hangisinin baskın olduğunu ekip belirler.

## ORM ne satın alır

ORM'in gerçek getirileri var ve bunlar küçümsenmemeli:

- **Güvenlik.** Sorgular varsayılan olarak parametrelidir; sıradan kullanımda SQL injection yüzeyi kapalıdır.
- **Okunabilirlik.** CRUD işlemleri için `User::create($data)`, elle yazılmış `INSERT`'ten kısa ve nettir.
- **Daha az tekrar.** İlişkiler, migration'lar, model event'leri — hepsi tek yerden.

Projelerin büyük çoğunluğu özünde CRUD'dur ve bu işler için ORM doğru varsayılandır. Buna itirazım yok.

## ORM'in tembelleştirdiği yer

Tehlike ORM'in ne yaptığında değil, ne **gizlediğinde**. ORM, SQL'i gözden kaldırır; geliştirici SQL'i görmeyince hangi sorgunun çalıştığını düşünmeyi bırakır.

Sonuç tanıdık: yazının başındaki N+1; tek bir kolon yetecekken tüm satırı belleğe çekmek; bir `where` unutup farkında olmadan tüm tabloyu yüklemek. Bunların hiçbirini ORM "yapmaz"; hepsini, ORM'in ne ürettiğine bakmayan geliştirici yapar.

[Veri yoğunluklu sistemler](/tr/systems/veri-yogunluklu-sistemler-kirilma-noktalari) yazısındaki yanlış kırılma noktaları tablosunun ilk satırı tam da budur: "veritabanı yavaş" sanılan şey, çoğu zaman uygulamanın 200 sorgu atmasıdır.

## ORM nerede biter

ORM, transactional CRUD'da parlar: bir kaydı oluştur, güncelle, ilişkileriyle oku. Zorlandığı yer de bellidir:

- Çok tablolu, çok adımlı raporlar.
- Agregasyonlar, window function'lar, `GROUP BY` üstüne karmaşık koşullar.
- Toplu işlemler — milyonlarca satırı tek tek model olarak gezmek yerine tek bir `UPDATE`.

Bu işlerde ORM ile ısrar etmek hem daha yavaş hem daha az okunur kod üretir. Düz SQL burada hem daha hızlı hem daha nettir. Doğru indeksleri seçmek de bu işin parçası — [indeks yönetimi](/tr/notes/indeks-yonetimi) notu o tarafı anlatıyor.

## Karar: ORM varsayılan, SQL araç

İkisi rakip değil. Doğru kullanım kabaca şu:

- İşlerin %90'ı — CRUD, basit listeler — ORM ile. Hızlı, güvenli, okunur.
- Kalan %10 — ağır raporlama, agregasyon, toplu işlem — query builder veya düz SQL ile.

Kıdem göstergesi, ORM'i bilmek değil; **nerede bittiğini** bilmektir. ORM'i her şeye zorlayan ekip onu bir performans tuzağına çevirir; ORM'i hiç kullanmayıp her şeyi elle yazan ekip ise güvenlik ve okunabilirlikten boş yere ödün verir.

## İkisi de güvenli yazılabilir

Yaygın bir yanlış: "düz SQL = güvensiz". Güvenliği sağlayan ORM değil, **parametre bağlamadır**. Bağlı parametrelerle yazılmış düz bir sorgu, ORM kadar injection'a kapalıdır:

```php
DB::select('SELECT id, total FROM orders WHERE status = ?', ['pending']);
```

Tehlikeli olan düz SQL değil; string birleştirmeyle kullanıcı girdisini sorguya gömmektir — ve bunu ORM'in `whereRaw`'ında da yapabilirsiniz. Araç değil, alışkanlık korur.

---

ORM bir tembellik makinesi de olabilir, bir güvenlik ağı da — farkı, ekibin ona nasıl baktığı yaratır. Onu kullanın, ama ne ürettiğini görmeyi hiç bırakmayın.

İyi geliştirici ORM ile yazar; ne zaman ORM'i bırakacağını da bilir.