SQL + AI Workshop’ları: Var Olan Veritabanına AI Ekleme

Şunu fark ettim: Açık konuşayım. Son altı aydır müşteri görüşmelerinde aynı soruyu duymaktan kulaklarım çınlıyor: “Aşkın, biz 12 yıldır SQL Server üzerinde dönen bir ERP’ye sahibiz. Şimdi herkes AI diyor. Biz baştan mı yazacağız?”

Cevap kısa: Hayır.

Geçen hafta Microsoft, dünya genelinde partnerleri üzerinden SQL AI App in a Day adlı bir workshop serisi başlattığını duyurdu. Ücretsiz, tam gün, eli kirleten tarzda bir etkinlik. Konu da tam olarak yukarıdaki soruya cevap veriyor: Var olan SQL altyapını çöpe atmadan, üstüne AI nasıl koyarsın?

Ben bu yazıda hem workshop’un ne anlatacağını hem de — daha önemlisi — Türkiye’deki kurumsal yapılar için bunun ne anlama geldiğini paylaşacağım. Çünkü bir İstanbul’daki bankanın SQL Server’ında veri varsa, o veriyi taşımadan AI eklemek artık fantezi değil.

Önce Şunu Konuşalım: Neden Herkes Panik Modunda?

Bakın şimdi, son iki yılda AI tarafında öyle bir koşu başladı ki, sektördeki çoğu kişi sanki bir şeyleri kaçırıyormuş gibi davranıyor. Her hafta yeni bir platform çıkıyor, yeni bir pattern geliyor, üstüne bir de “doğru yöntem” diye sunulan başka bir şey ekleniyor; açık konuşayım, insanın kafası doğal olarak karışıyor.

İşin garibi, Kısa cevap şu: panik biraz fazla. Bakın, peki neden? Çünkü yıllardır SQL üzerinde iş kuralı yazan, T-SQL ile stored procedure tasarlayan, indeks stratejisini kurcalayıp durarak sistemi toparlayan ekiplerin “hadi sıfırdan başlayalım” demesi pek mantıklı değil; veri zaten orada duruyor, o hâlde niye yerinden oynatalım?

Hmm, bunu nasıl anlatsamdı…

İşin aslı da burada çıkıyor ortaya. Microsoft’un son birkaç sürümde SQL Server ve Azure SQL’e eklediği parçalar tam bu noktaya dokunuyor (ve bence fena da olmamış), vektör veri tipleri, native embedding fonksiyonları, T-SQL içinden REST API çağırma kabiliyeti gibi şeyler var; üstüne yeni Microsoft SQL Server 2025 de baya iyi bir yere gelmiş durumda. Evet.

“AI ile gelen yönetişim soruları — doğru cevap, korunan veri, kontrollü model erişimi — aslında SQL geliştiricilerinin yıllardır zaten çözdüğü sorular. Kelime dağarcığı biraz değişti, hepsi o.”

Workshop’ta Tam Olarak Ne Yapılıyor?

Bunu yaşayan biri olarak söyleyeyim, Programa bakınca şunu gördüm: gün boyu oturup dinleme yok, işin aslı bir şeyler kuruyorsun. Slayt eziyeti de pek yok, iyi tarafı bu. Baya rahatlatıyor. Aşağıdaki adımları tek oturumda, kendi laptop’unda yapıyorsun:

• Tanıdık T-SQL pattern’leriyle başlıyorsun — yani CRUD, JOIN, view… bildiğimiz yerden — ciddi fark yaratıyor
• Embedding üretip vektör sütunlarda saklıyorsun (relational tabloların yaninda, ayrı bir vector DB’ye taşımadan)
• Vector search yapıyorsun — cosine distance falan
• RAG (Retrieval-Augmented Generation) kuruyorsun. Yani LLM’e kendi verinle cevap verdiriyorsun
• Latency, maliyet, doğruluk ve yönetişim arasındaki tradeoff’ları gerçek bir mühendis gibi tartıyorsun

Açıkçası, Bu son madde bence asıl mesele. POC’da her şey tatlı görünüyor, sonra production’a geçince tablo biraz değişiyor. Hatta baya değişiyor. 50.000 sorgu/dakika gelince ne ölür, sistem nereye dayanir, nerede tökezler; workshop tam da bunu konuşuyor gibi duruyor.

Çok konuştum, örnekle göstereyim.

Bir Örnek: SQL İçinde Vector Search Nasıl Görünür?

Bi saniye — Şöyle düşünün, daha net oluyor. Peki bunu neden söylüyorum? Diyelim ki elinizde bir e-ticaret veritabanı var ve ürün açıklamalarında semantic search istiyorsunuz; SQL Server 2025 tarafında bunu artık doğrudan T-SQL ile çevirmeye başlayabiliyorsunuz:

-- Vektör sütunu ekleyelim
ALTER TABLE Products
ADD description_embedding VECTOR(1536);
-- Embedding üret ve sakla (Azure OpenAI üzerinden)
UPDATE Products
SET description_embedding = AI_GENERATE_EMBEDDINGS(description 
USE MODEL 'text-embedding-3-small');
-- Semantic search: "su geçirmez kış botu" gibi
DECLARE @query_vector VECTOR(1536) = 
AI_GENERATE_EMBEDDINGS(@user_query USE MODEL 'text-embedding-3-small');
SELECT TOP 10 ProductId, Name, 
VECTOR_DISTANCE('cosine', description_embedding, @query_vector) AS similarity
FROM Products
ORDER BY similarity ASC;

Bak şimdi, burada yeni bir dünya kurmuyorsun. Aynı T-SQL var, aynı tablo var, sadece araya bir vektör sütunu ve birkaç fonksiyon giriyor. Bir DBA’in bunu anlaması yarım gün sürer mi? Muhtemelen hayır bile denebilir. Ayrı Pinecone, Weaviate ya da Qdrant ayağa kaldırmadan da yol alabiliyorsun.

Aslında, Tabi bir de performans tarafı var; ben ilk baktığımda açıkçası temkinliydim. 5 milyon kayıtlık tabloda vector search kaç saniye sürer diye düşündüm (hatta içimden “burada biraz yavaşlar” dedim), ama uygun indeksle DiskANN bazlı yapı gerçekten fena değilmiş; 100ms altına inebiliyor. Yine de şunu dürüstçe söyleyeyim: 50 milyon kayıt üstünde test etmedim, oradaki davranış için net konuşamam.

Hmm, bunu nasıl anlatsamdı…

Türkiye Açısından Bu Neden Önemli?

Şimdi asıl yere gelelim. Türkiye’deki kurumsal yapıların çoğu, (söylemesi ayıp) özellikle finans, sigorta, kamu ve telekom tarafı, SQL Server üstünde dönüyor. Bir kısmı da buluta bakıyor ama tam geçemiyor; KVKK, BDDK derken iş biraz ağırlaşıyor, yani hibrit çalışmak çoğu ekip için daha gerçekçi kalıyor.

Açıkçası, Geçen ay bir bankacılık işinde aynen şu soru geldi: “Müşteri kayıtlarımızı vektör veritabanına dump’layıp Pinecone’a atalım mı?” Ben de içimden “dür bakalım” dedim. Çünkü mesele sadece teknik değil:

1. O veri zaten SQL Server’da duruyor. Niye bir de başka yere taşıyalım?
2. İki yerde tutunca senkron işi uzuyor, sonra küçük bir fark büyüyüp baş ağrısına dönüyor.
3. Bir de güvenlik tarafı var; iki ayrı sistem, iki ayrı kontrol seti demek.
4. Ve en önemlisi, KVKK denetiminde “veriniz tam olarak nerede?” sorusuna tek cevap veremiyorsunuz.

Size bir şey söyleyeyim, SQL içinde vektör saklamak bence işin güzel tarafı burada başlıyor. Aynı row-level security, aynı Always Encrypted, aynı audit log; üstüne bir de veri katmanı değişmiyor. Banka CISO’sunun bakıp “tamam, bunu ben anlarım” diyebileceği bir kurgu çıkıyor ortaya. Bu önemli, çünkü yeni bir şeyin sahaya inmesi için sadece geliştirici ikna olmuyor; CISO da onay vermezse iş orada kalıyor.

Enterprise vs Startup: İki Farklı Hikâye

Burada bir parantez açayım. Çünkü bu workshop’un mesajı her şirkete aynı değil, hatta bazen aynı cümle başka ekipte bambaşka yere gidiyor.

Küçük Bir Ekipseniz

İnanın, 10 kişilik bir SaaS startup’ıysanız (kendi tecrübem). Yeni bir ürün geliştiriyorsanız, açık konuşayım: SQL Server’da vector search yapmak sizin için zorunlu değil. Belki bir Cosmos DB Güvenliği: Yeni Projede İlk Gün Kararları yazımda anlattığım gibi NoSQL bir yapı ya da dedicated bir vector DB size daha esnek gelir. Çünkü ortada korunacak eski yatırım yok, sıfırdan oynuyorsunuz.

İşte tam da bu noktada devreye giriyor.

Kurumsal Bir Yapıdaysanız

Ama 5000 çalışanlı bir kurumsanız ve 15 yıllık bir CRM’ınız varsa… iş değişiyor. Sizin için “yeniden başla” demek 18 aylık proje, üstüne de 5 milyon dolar bütçe demek olabilir; SQL’in içinde AI kurmak işe belki 3 ayda toparlanır. İlginç, değil mi? Tabi bu kaba bir kıyas, ama ölçek hissi fena vermiyor.

Aşağıda iki yaklaşımı yan yana koyan basit bir tablo hazırladım:

Kriter	SQL İçinde AI (RAG)	Ayrı Vector DB + SQL
Kurulum süresi	Birkaç gün	Haftalar
Veri tutarlılığı	Tek kaynak (ACID)	Senkronizasyon riski
Güvenlik modeli	Mevcut RLS, audit	İki ayrı model
Aylık maliyet (orta ölçek)	Mevcut SQL + ~%15-20	+ Pinecone/Weaviate lisansı
Ölçeklenme tavanı	Yüksek ama sonlu	Çok yüksek
Operasyonel yük	DBA ekibi yeter	Yeni uzmanlık gerekir

Evet, her şeyin bir bedeli var. Ben şahsen kurumsal müşterilerime önce SQL içinde başlamayı, sonra ihtiyaç büyürse ayırmayı öneriyorum. Erken optimizasyon diye peşine düştüğünüz şey bazen sızı gereksiz yere oyalıyor, hani işin aslı biraz da bu.

Daha açık söyleyeyim, peki neden?

Dürüst cevap şu:

Bir şey dikkatimi çekti: Küçük ekiplerde hız önemli olurken, büyük yapılarda mevcut sistemleri korumak daha mantıklı geliyor. Mesele teknoloji seçmekten çok, o — kendi adıma konuşayım — teknolojiyi hangi yükün altında kullanacağınız oluyor. Bazen de en düzgün görünen mimarı değil, en az sürtünme çıkaran yol kazanıyor.

Kısacası, bunu yaşayan biri olarak söyleyeyim, Tam da öyle.

Maliyet Tarafı: TL Bazında Konuşalım

Şimdi biraz sıkıcı, ama mecburen giriyoruz bu kısma. Azure SQL Database üzerinde vector search yapmanın TL bazlı maliyetine bakalım, kabaca tabi; kur oynuyor, o yüzden milimetrik rakam vermek zaten biraz hayal işi.

Orta ölçek bir senaryo düşünelim. 1 milyon ürünlü bir kataloğunuz var, günde 100 bin kullanıcı sorgusu geliyor, bir de embedding modeli olarak text-embedding-3-small kullanıyorsunuz. Kağıt üstünde basit duruyor, pratikte işe detaylar hemen ortaya çıkıyor. Bu konuyla ilgili Visual Studio 2026 C++ Yenilikleri: 18.1’den 18.6’ya Saha yazımıza da göz atmanızı tavsiye ederim.

• Embedding üretimi (bir kerelik): 1M ürün × ~100 token = 100M token. text-embedding-3-small için yaklaşık $2 ediyor. Yani kabaca 70-80 TL civarı. Evet, bu kadar.
• Aylık sorgu embedding’i: 100K × 30 gün × ~20 token = 60M token. Yaklaşık $1.2/ay yapıyor. Hani şu meşhur “çok da bir şey değil” dediğimiz kalemlerden biri; 40 TL falan. — ciddi fark yaratıyor
• SQL ek depolama: 1M × 1536 boyut × 4 byte = yaklaşık 6 GB. Azure SQL tarafında buna bakınca insanın aklına hemen büyük bir fatura gelmiyor, çünkü açık konuşayım, neredeyse hesaba katılmıyor.
• LLM çağrıları (GPT-4o-mini varsayalım, RAG için): İşin asıl pahalı tarafı burası. Sorgu başına yaklaşık ~1500 token in, ~300 token out gidiyor; aylık 100K × 30 × $0.0005 hesabı da yaklaşık $1500/ay ediyor. Yani kabaca 50.000 TL civarı.

Şunu söyleyeyim, Yani işin omurgası LLM tarafında duruyor. Vector search kısmının maliyeti baya düşük kalıyor, hatta bazı senaryolarda insan şaşırıyor açıkçası. Kısacası, peki neden? Çünkü parayı asıl yakan yer retrieval değil, modelin kendisi ve ona taşıdığınız bağlam oluyor.

Bakın, Neyse, çok dağıtmadan söyleyeyim: Optimizasyon yapacaksanız önce RAG için context window’u kısaltmaya bakın, sonra gereksiz LLM çağrılarını azaltın (bizzat test ettim). SQL tarafı zaten ucuz kalıyor; orada saatlerce uğraşsanız da tablo pek değişmiyor. Daha fazla bilgi için A2A v1 Geldi: Agent’lar Artık Aynı Dili Konuşuyor yazımıza bakabilirsiniz.

Saha Notu: İlk Denememdeki Hata

Açıkçası, Bir hikâye anlatayım. 2024 sonunda bir lojistik şirketinde POC yapıyorduk. Müşteri talebi şuydu: “Sevkiyat notlarında semantic search istiyoruz.” Tabi biz de heyecanlandık, embedding’leri ürettik, vector search yazdık; demo tarafı gayet iyi aktı, hatta ilk bakışta iş çözülmüş gibi durdu. Bu konuyla ilgili NL2SQL Gerçekten İşe Yarıyor mu? SQL MCP Server Notları yazımıza da göz atmanızı tavsiye ederim.

Production’a aldığımız ilk hafta müşteri aradı: “Aşkın, sistem cevap veremiyor.” Sebep neymiş bakın — embedding’leri her gece batch ile güncelliyorduk ama yeni eklenen notlar için trigger eklemeyi unutmuşuz. Yani yeni bir not yazıldığında embedding üretilmiyordu, kullanıcı da o notu arayınca doğal olarak boş dönüyordu. İşte, peki neden?

Bunu biraz açayım. Bu konuyla ilgili .NET MAUI Android’de Material 3: Tek Satırda Yenilenme yazımıza da göz atmanızı tavsiye ederim.

Çözüm aslında basitti: Bir AFTER INSERT trigger’ı yazıp embedding’i anlık üretmek. Ama dür bir saniye — bu sefer de başka bir dert çıktı; insert işlemi 50ms iken 800ms’ye fırladı çünkü Azure OpenAI’a çağrı atıyordu, yani veritabanı tarafında küçük görünen karar uygulama akışını tek başına ağırlaştırdı. Sonunda Service Bus üzerinden async bir kuyruğa attık, embedding generation arka planda oldu.

Yani lafın özü şu: Mimarı kararları lab’da değil, production senaryosunu düşünerek alın. Workshop’ta bu tarz tradeoff’ların konuşulacak olması benim için en değerli kısım gerçi. Evet.

Sertifika ve İlerleme Yolu

Bu arada şunu da söylemeden geçmeyeyim: Microsoft SQL AI Developer sertifikasını GA yaptı. Yani ortada artık resmî bir yol var, lafı dolandırmaya gerek yok. Workshop’a katıldıktan sonra hazırlanmak isteyenler için fena olmayan bir hedef çıkıyor ortaya, hatta bence işin en toparlayıcı kısmı da bu.

Benim önerim şöyle bir sıra:

1. Önce workshop’a katıl (ücretsiz, pratik) — bunu es geçmeyin
2. Sonra Microsoft Learn üzerinden ilgili modülleri tamamla
3. Bir POC projesinde uygula (kendi şirketinde küçük bir use case bul) — ciddi fark yaratıyor
4. Sertifikaya hazırlan ve gir (bu kritik)

İlk adım basit. Sonra iş biraz açılıyor. Cosmos Conf 2026: AI Çağında Veritabanı Nereye Gidiyor? yazımızda bu konuya da değinmiştik.

Bu sıralama çoğu kişi için işe yarıyor, çünkü teori önce gelince insanın gözü kayıyor, pratik önce gelince de bu sefer temel boş kalabiliyor; workshop işe ikisini aynı sepete koyuyor gibi duruyor, yani ne tamamen kuru bilgi ne de sadece deneme-yanilma oluyor. Hani tam ortası var ya, işte orası baya iş görüyor.

Workshop’a Nasıl Katılınır?

Etkinlikleri Microsoft partnerleri düzenliyor, dünya genelinde farklı şehirlerde; Türkiye tarafında da büyük ihtimalle birkaç oturum açılır, özellikle İstanbul ve Ankara’da — itiraf edeyim, beklentimin üstündeydi —. Microsoft’un resmî SQL AI App in a Day events kataloğunu takıp etmek lazım. Peki neden? Çünkü kayıtlar bazen sessiz sedasız açılıyor, sonra bir bakıyorsunuz kontenjan gitmiş.

Bir tavsiyem var. Eğer kendi şirketinizden 3-4 kişi gidebilirseniz, dönüşte iç eğitim verecek bir core team oluşturmuş olursunuz; açık konuşayım, bu iş tek kişinin “gittim gördüm” notundan çok daha fazla işe yarıyor, çünkü içeride anlatınca konu oturuyor, sorular geliyor ve bilgi biraz dağınık kalmıyor. Evet.

Benzer bir yaklaşımı T-SQL’de Regex Artık LOB’u da Yutuyor: 2 MB Devri yazımda da konuşmuştuk — SQL Server dünyaine eklenen yeni özelliklerin sahaya inmesi için ekip içi bilgi paylaşımı şart. Yoksa özellik var ama kimse kullanmıyor; garip ama oluyor işte.

Peki eksikler ne? Çünkü her şey pembe değil

Eleştirel olayım biraz. SQL içinde vektör tutmak baya iş görüyor ama, bak şimdi, birkaç sınır da var:

• Çok yüksek ölçek (100M+ vektör): Bu noktada dedicated vector DB’ler hâlâ daha hızlı kalıyor. SQL Server fena değil, ama Pinecone gibi bu işe iyice optimize edilmiş çözümlerin tatlı noktasına aynı ölçekte giremiyor.
• Multi-modal arama: Görsel + metin gibi karışık embedding senaryolarında ekosistem henüz çok olgun değil. Yapılıyor tabii, ama elinizi biraz kirletmeniz gerekiyor, yani o kadar temiz akmıyor.
• Model yönetimi: Embedding modelinizi değiştirmek istediğinizde bütün vektörleri yeniden üretmek gerekiyor; büyük tablolarda bu iş insanın canını sıkabiliyor, açık konuşayım.

Aslında, Yani kağıt üstünde tablo hoş duruyor. Ama pratikte bazı kenar köşelerin biraz daha pişmesi lazım, hâlâ öyle. Microsoft hızlı gidiyor, bunu inkâr edemem; önümüzdeki bir yılda bu boşlukların çoğunun kapanacağını düşünüyorum. Ama bugün karar verirken bunları cebinizde tutun.

Evet.

Pratik İlk Adımlar

Bu yazıyı okuyup “Tamam, ben de denemek istiyorum” diyorsanız, bence en mantıklısı küçükten başlamak. Hani önce ortamı kurarsınız, sonra biraz kurcalarsınız, bir şeyler bozulur, sonra düzelir; işte o döngü çoğu zaman en sağlıklısı oluyor.

1. SQL Server 2025 veya Azure SQL Database üzerinde küçük bir test ortamı kurun
2. Azure OpenAI Service’te bir text-embedding-3-small deployment’ı oluşturun (ucuz ve hızlı)
3. Mevcut tablolarınızdan birinde — ürünler, dokümanlar, ticketlar — 1000 kayıtla başlayın
4. Yukarıdaki kod örneğinden yola çıkıp embedding üretip vector search yapın
5. Sonuçları gözden geçirin: Anlamlı mı? Hızlı mı? Production’a uyar mı? (bu kritik)
6. Workshop’a kayıt olun ve oradan derinleşin — bunu es geçmeyin

Peki neden böyle gidiyoruz? Çünkü doğrudan büyük veriyle dalmak yerine, önce ufak bir setle bakınca hem maliyet tarafını hem de sorgu davranışını daha net görüyorsunuz; açık konuşayım, ilk denemede “valla bu iş oldu” hissi gelirse devam etmek çok daha kolay oluyor.

Evet.

Bir de şunu unutmayın: embedding tarafında sonuç güzel görünse bile, asıl mesele sizin senaryonuzda işe yarayıp yaramadığıdır (mesela arama kalitesi mi önemli, yoksa gecikme mi), yani biraz ölçüp biçmeden karar vermeyin. Siz ne dersiniz?

Neyse uzatmayalım. Workshop kısmı da tam burada devreye giriyor; elinizdeki örneği alıp biraz daha didiklemek, farklı veri tiplerinde denemek. Sonra kendi kullanımınıza uyarlamak için fena olmayan bir zemin sağlıyor.

Sıkça Sorulan Sorular

SQL AI App in a Day workshop’una katılmak ücretli mi?

Hayır, tamamen bedava. Microsoft partnerleri organize ediyor, kayıt yaptırman yeterli. Aslında tek “maliyet” diyebileceğin şey gününü ayırman. Genelde laptop getirmeni istiyorlar, Azure hesabı için de trial credit gayet yetiyor.

SQL Server 2022’de vector search yapabilir mıyım?

Native vector tipiyle direkt olarak hayır, açıkçası mümkün değil. Vector veri tipi ve fonksiyonları Azure SQL Database ile SQL Server 2025’e geldi. SQL Server 2022’de VARBINARY ile tutup uygulama tarafında hesaplama yapan workaround’lar var, ama bence bu yol çok zahmetli — hem de performans olarak native çözümün oldukça gerisinde kalıyor. Native özellikler istiyorsan sürüm güncellemesi şart.

Şimdi gelelim işin can alıcı noktasına.

RAG yaparken hangi embedding modelini kullanmalıyım?

Genel kullanım için text-embedding-3-small fiyat/performans dengesi açısından gerçekten çok iyi. Daha yüksek doğruluk lazımsa text-embedding-3-large‘a geçebilirsin, ama yaklaşık 5 kat daha pahalı oluyor. Türkçe içerikte ikisi de çalışıyor; large model nüansları biraz daha iyi yakalıyor tecrübeme göre. Medikal ya da hukuk gibi çok özel bir domain’in varsa fine-tune edilmiş modelleri de düşünebilirsin.

Verim KVKK kapsamında, AI’a göndermeden RAG yapabilir mıyım?

Tamamen offline gitmek istiyorsan on-premise LLM’lerle (mesela Llama, Mistral) SQL Server 2025’i birlikte kullanabilirsin. Ama bu setup ciddi bir GPU yatırımı gerektiriyor, bunu baştan söyleyeyim. Bence çok daha makul olan hibrit yaklaşım şu: veriyi SQL’de tut, sadece sorgu anında anonimleştirilmiş context’i Türkiye veya AB bölgesindeki Azure OpenAI’a gönder. Zaten çoğu kurumsal denetim bu yapıyı kabul ediyor.

Şimdi gelelim işin can alıcı noktasına.

Workshop bittikten sonra ne yapmalıyım?

Workshop güzel bir başlangıç noktası, yani temeli atıyor. Ama işin asıl tadı sahaya inince çıkıyor — kendi şirketinde küçük bir use case bulman lazım. Bence başlangıç için en uygun üç proje şunlar: iç dokümantasyon arama, ticket benzerlik analizi ve ürün öneri sistemi. Bu üçü hem gerçek iş değeri yaratıyor hem de POC olarak yönetime sunması çok daha kolay oluyor (bu beni çok şaşırttı)

Kaynaklar ve İleri Okuma

Garip gelecek ama, Orijinal Duyuru: SQL + AI, hands-on workshop (Microsoft DevBlogs)

Şunu söyleyeyim, Intelligent applications with Azure SQL Database (Microsoft Learn)

Açıkçası, SQL Server Vector Data Type Resmî Dokümantasyonu (buna dikkat edin)

Azure SQL Vector Search Örnekleri (GitHub)