{"id":4470,"date":"2026-02-04T22:58:56","date_gmt":"2026-02-04T19:58:56","guid":{"rendered":"https:\/\/www.dchost.com\/blog\/kucuk-saas-ve-api-projeleri-icin-multi-tenant-veritabani-ve-hosting-rehberi\/"},"modified":"2026-02-04T22:58:56","modified_gmt":"2026-02-04T19:58:56","slug":"kucuk-saas-ve-api-projeleri-icin-multi-tenant-veritabani-ve-hosting-rehberi","status":"publish","type":"post","link":"https:\/\/www.dchost.com\/blog\/kucuk-saas-ve-api-projeleri-icin-multi-tenant-veritabani-ve-hosting-rehberi\/","title":{"rendered":"K\u00fc\u00e7\u00fck SaaS ve API Projeleri \u0130\u00e7in Multi\u2011Tenant Veritaban\u0131 ve Hosting Rehberi"},"content":{"rendered":"<div class=\"dchost-blog-content-wrapper\"><div id=\"toc_container\" class=\"toc_transparent no_bullets\"><p class=\"toc_title\">\u0130&ccedil;indekiler<\/p><ul class=\"toc_list\"><li><a href=\"#Kucuk_SaaS_ve_API_Projelerinde_MultiTenant_Veritabani_Neden_Kritik\"><span class=\"toc_number toc_depth_1\">1<\/span> K\u00fc\u00e7\u00fck SaaS ve API Projelerinde Multi\u2011Tenant Veritaban\u0131 Neden Kritik?<\/a><\/li><li><a href=\"#MultiTenant_Veritabani_Nedir_Tekil_Mimardan_Farki_Ne\"><span class=\"toc_number toc_depth_1\">2<\/span> Multi\u2011Tenant Veritaban\u0131 Nedir, Tekil Mimardan Fark\u0131 Ne?<\/a><\/li><li><a href=\"#MultiTenant_Veritabani_Mimarisi_Turleri\"><span class=\"toc_number toc_depth_1\">3<\/span> Multi\u2011Tenant Veritaban\u0131 Mimarisi T\u00fcrleri<\/a><ul><li><a href=\"#1_Tek_Veritabani_Ortak_Sema_Shared_DB_Shared_Schema\"><span class=\"toc_number toc_depth_2\">3.1<\/span> 1) Tek Veritaban\u0131, Ortak \u015eema (Shared DB, Shared Schema)<\/a><\/li><li><a href=\"#2_Tek_Veritabani_Ayri_Sema_Shared_DB_Isolated_Schema\"><span class=\"toc_number toc_depth_2\">3.2<\/span> 2) Tek Veritaban\u0131, Ayr\u0131 \u015eema (Shared DB, Isolated Schema)<\/a><\/li><li><a href=\"#3_Her_Musteriye_Ayri_Veritabani_Database_per_Tenant\"><span class=\"toc_number toc_depth_2\">3.3<\/span> 3) Her M\u00fc\u015fteriye Ayr\u0131 Veritaban\u0131 (Database per Tenant)<\/a><\/li><li><a href=\"#4_Hibrit_Modeller_Buyukler_Ayri_Kucukler_Ortak\"><span class=\"toc_number toc_depth_2\">3.4<\/span> 4) Hibrit Modeller: B\u00fcy\u00fckler Ayr\u0131, K\u00fc\u00e7\u00fckler Ortak<\/a><\/li><\/ul><\/li><li><a href=\"#Kucuk_SaaS_ve_API_Projeleri_Icin_Dogru_Mimarinin_Secimi\"><span class=\"toc_number toc_depth_1\">4<\/span> K\u00fc\u00e7\u00fck SaaS ve API Projeleri \u0130\u00e7in Do\u011fru Mimarinin Se\u00e7imi<\/a><ul><li><a href=\"#Asama_1_MVP_ve_Ilk_1020_Musteri\"><span class=\"toc_number toc_depth_2\">4.1<\/span> A\u015fama 1: MVP ve \u0130lk 10\u201320 M\u00fc\u015fteri<\/a><\/li><li><a href=\"#Asama_2_50200_Musteri_ve_Artan_Yuk\"><span class=\"toc_number toc_depth_2\">4.2<\/span> A\u015fama 2: 50\u2013200 M\u00fc\u015fteri ve Artan Y\u00fck<\/a><\/li><li><a href=\"#Asama_3_Kurumsal_Musteriler_Cografi_Yayilim_ve_Uyumluluk\"><span class=\"toc_number toc_depth_2\">4.3<\/span> A\u015fama 3: Kurumsal M\u00fc\u015fteriler, Co\u011frafi Yay\u0131l\u0131m ve Uyumluluk<\/a><\/li><\/ul><\/li><li><a href=\"#Veritabani_Tasarim_Detaylari_Izolasyon_Guvenlik_ve_Performans\"><span class=\"toc_number toc_depth_1\">5<\/span> Veritaban\u0131 Tasar\u0131m Detaylar\u0131: \u0130zolasyon, G\u00fcvenlik ve Performans<\/a><ul><li><a href=\"#Tenant_Kimligi_ve_Satir_Bazli_Izolasyon\"><span class=\"toc_number toc_depth_2\">5.1<\/span> Tenant Kimli\u011fi ve Sat\u0131r Bazl\u0131 \u0130zolasyon<\/a><\/li><li><a href=\"#Index_Tasarimi_tenant_id_Sik_Kullanilan_Alanlar\"><span class=\"toc_number toc_depth_2\">5.2<\/span> Index Tasar\u0131m\u0131: tenant_id + S\u0131k Kullan\u0131lan Alanlar<\/a><\/li><li><a href=\"#Sema_Degisiklikleri_Migration_ve_Geri_Alma_Stratejisi\"><span class=\"toc_number toc_depth_2\">5.3<\/span> \u015eema De\u011fi\u015fiklikleri (Migration) ve Geri Alma Stratejisi<\/a><\/li><li><a href=\"#Gizlilik_ve_Uyumluluk_Tenant_Bazli_Yedek_ve_Silme\"><span class=\"toc_number toc_depth_2\">5.4<\/span> Gizlilik ve Uyumluluk: Tenant Bazl\u0131 Yedek ve Silme<\/a><\/li><\/ul><\/li><li><a href=\"#Hosting_Mimarisi_MultiTenant_Veritabanini_Nereye_Koymali\"><span class=\"toc_number toc_depth_1\">6<\/span> Hosting Mimarisi: Multi\u2011Tenant Veritaban\u0131n\u0131 Nereye Koymal\u0131?<\/a><ul><li><a href=\"#1_Tek_VPS_Uzerinde_Uygulama_Veritabani\"><span class=\"toc_number toc_depth_2\">6.1<\/span> 1) Tek VPS \u00dczerinde Uygulama + Veritaban\u0131<\/a><\/li><li><a href=\"#2_Ayri_Veritabani_Sunucusuna_Gecmek\"><span class=\"toc_number toc_depth_2\">6.2<\/span> 2) Ayr\u0131 Veritaban\u0131 Sunucusuna Ge\u00e7mek<\/a><\/li><li><a href=\"#3_Cok_VPSli_Mimari_Replikasyon_ve_Yuksek_Erisilebilirlik\"><span class=\"toc_number toc_depth_2\">6.3<\/span> 3) \u00c7ok VPS\u2019li Mimari, Replikasyon ve Y\u00fcksek Eri\u015filebilirlik<\/a><\/li><\/ul><\/li><li><a href=\"#Operasyonel_Konular_Yedekleme_Deploy_ve_Tenant_Tasima\"><span class=\"toc_number toc_depth_1\">7<\/span> Operasyonel Konular: Yedekleme, Deploy ve Tenant Ta\u015f\u0131ma<\/a><ul><li><a href=\"#Yedekleme_Stratejisi_Tum_DB_mi_Tenant_Bazli_mi\"><span class=\"toc_number toc_depth_2\">7.1<\/span> Yedekleme Stratejisi: T\u00fcm DB mi, Tenant Bazl\u0131 m\u0131?<\/a><\/li><li><a href=\"#ZeroDowntime_Dagitim_ve_Sema_Degisiklikleri\"><span class=\"toc_number toc_depth_2\">7.2<\/span> Zero\u2011Downtime Da\u011f\u0131t\u0131m ve \u015eema De\u011fi\u015fiklikleri<\/a><\/li><li><a href=\"#Belirli_Bir_Tenanti_Tasimak_Ortak_DBden_Ayri_Veritabanina\"><span class=\"toc_number toc_depth_2\">7.3<\/span> Belirli Bir Tenant\u2019\u0131 Ta\u015f\u0131mak: Ortak DB\u2019den Ayr\u0131 Veritaban\u0131na<\/a><\/li><\/ul><\/li><li><a href=\"#DCHost_Uzerinde_Pratik_Mimari_Onerileri\"><span class=\"toc_number toc_depth_1\">8<\/span> DCHost \u00dczerinde Pratik Mimari \u00d6nerileri<\/a><ul><li><a href=\"#Senaryo_1_Yeni_Baslayan_Kucuk_SaaS_API_MVP\"><span class=\"toc_number toc_depth_2\">8.1<\/span> Senaryo 1: Yeni Ba\u015flayan K\u00fc\u00e7\u00fck SaaS \/ API (MVP)<\/a><\/li><li><a href=\"#Senaryo_2_Buyuyen_SaaS_Artan_Trafik_ve_Musteri_Sayisi\"><span class=\"toc_number toc_depth_2\">8.2<\/span> Senaryo 2: B\u00fcy\u00fcyen SaaS, Artan Trafik ve M\u00fc\u015fteri Say\u0131s\u0131<\/a><\/li><li><a href=\"#Senaryo_3_Kurumsal_Musteriler_ve_Yuksek_Erisilebilirlik\"><span class=\"toc_number toc_depth_2\">8.3<\/span> Senaryo 3: Kurumsal M\u00fc\u015fteriler ve Y\u00fcksek Eri\u015filebilirlik<\/a><\/li><\/ul><\/li><li><a href=\"#API_Katmani_ve_Rate_Limitingi_Unutmamak\"><span class=\"toc_number toc_depth_1\">9<\/span> API Katman\u0131 ve Rate Limiting\u2019i Unutmamak<\/a><\/li><li><a href=\"#Ozet_ve_Sonraki_Adimlar\"><span class=\"toc_number toc_depth_1\">10<\/span> \u00d6zet ve Sonraki Ad\u0131mlar<\/a><\/li><\/ul><\/div>\n<h2><span id=\"Kucuk_SaaS_ve_API_Projelerinde_MultiTenant_Veritabani_Neden_Kritik\">K\u00fc\u00e7\u00fck SaaS ve API Projelerinde Multi\u2011Tenant Veritaban\u0131 Neden Kritik?<\/span><\/h2>\n<p>K\u00fc\u00e7\u00fck bir SaaS paneli ya da sadece birka\u00e7 endpoint\u2019ten olu\u015fan bir API geli\u015ftirirken ilk ba\u015fta her \u015fey basit g\u00f6r\u00fcn\u00fcr: tek veritaban\u0131, tek uygulama, tek sunucu. Ancak ilk 5\u201310 m\u00fc\u015fteriden sonra ayn\u0131 sorular d\u00f6nmeye ba\u015flar: M\u00fc\u015fteri verilerini nas\u0131l izole edece\u011fiz? Her yeni m\u00fc\u015fteri i\u00e7in ayr\u0131 veritaban\u0131 m\u0131 a\u00e7mal\u0131y\u0131z? Tek veritaban\u0131 b\u00fcy\u00fcd\u00fck\u00e7e performans ne olacak? Yedekleme ve kurtarma senaryolar\u0131nda kimi, nas\u0131l geri d\u00f6nd\u00fcrece\u011fiz?<\/p>\n<p>Multi\u2011tenant (\u00e7ok kirac\u0131l\u0131) veritaban\u0131 mimarisi tam bu noktada devreye girer. Ayn\u0131 uygulama kod taban\u0131n\u0131 kullanarak onlarca veya y\u00fczlerce m\u00fc\u015fteriyi, m\u00fcmk\u00fcn oldu\u011funca az operasyonel y\u00fckle ve uygun maliyetle bar\u0131nd\u0131rman\u0131z\u0131 sa\u011flar. Ancak yanl\u0131\u015f se\u00e7ilen mimari, ileride veri ta\u015f\u0131ma, raporlama, \u00f6l\u00e7ekleme ve g\u00fcvenlik taraf\u0131nda ciddi duvarlara \u00e7arpman\u0131za neden olabilir.<\/p>\n<p>Bu yaz\u0131da DCHost ekibi olarak, <strong>k\u00fc\u00e7\u00fck ve orta \u00f6l\u00e7ekli SaaS ve API projeleri<\/strong> i\u00e7in pratikte i\u015fe yarayan multi\u2011tenant veritaban\u0131 yakla\u015f\u0131mlar\u0131n\u0131 ve bunlar\u0131 hangi <strong>hosting mimarisi<\/strong> \u00fczerinde \u00e7al\u0131\u015ft\u0131rman\u0131z gerekti\u011fini ad\u0131m ad\u0131m ele alaca\u011f\u0131z. Daha \u00f6nce <a href=\"https:\/\/www.dchost.com\/blog\/saas-uygulamalari-icin-cok-kiracili-mimari-turleri-ve-dogru-hosting-altyapisi-secimi\/\">SaaS uygulamalar\u0131nda \u00e7ok kirac\u0131l\u0131 mimari t\u00fcrlerini daha derinlemesine anlatt\u0131\u011f\u0131m\u0131z rehberde<\/a> genel resmi \u00e7izmi\u015ftik; burada \u00f6zellikle veritaban\u0131 ve bar\u0131nd\u0131rma taraf\u0131ndaki somut karar noktalar\u0131na odaklanaca\u011f\u0131z.<\/p>\n<h2><span id=\"MultiTenant_Veritabani_Nedir_Tekil_Mimardan_Farki_Ne\">Multi\u2011Tenant Veritaban\u0131 Nedir, Tekil Mimardan Fark\u0131 Ne?<\/span><\/h2>\n<p>Basit\u00e7e s\u00f6ylemek gerekirse <strong>multi\u2011tenant veritaban\u0131 mimarisi<\/strong>, birden fazla m\u00fc\u015fterinin (tenant\u2019in) verisinin ayn\u0131 veritaban\u0131 altyap\u0131s\u0131 \u00fczerinde bar\u0131nd\u0131r\u0131ld\u0131\u011f\u0131 ama mant\u0131ksal, g\u00fcvenliksel ve \u00e7o\u011fu zaman performans a\u00e7\u0131s\u0131ndan birbirinden izole edildi\u011fi yap\u0131d\u0131r.<\/p>\n<p>Kar\u015f\u0131s\u0131nda ise <strong>single\u2011tenant<\/strong> yakla\u015f\u0131m vard\u0131r: Her m\u00fc\u015fteri i\u00e7in ayr\u0131 veritaban\u0131, hatta bazen tamamen ayr\u0131 sunucu kullan\u0131rs\u0131n\u0131z. Bu model izolasyon a\u00e7\u0131s\u0131ndan g\u00fc\u00e7l\u00fcd\u00fcr ama k\u00fc\u00e7\u00fck SaaS projeleri i\u00e7in:<\/p>\n<ul>\n<li>Y\u00f6netmesi zor (her m\u00fc\u015fteri i\u00e7in ayr\u0131 \u015fema g\u00fcncellemesi, yedek plan\u0131, izleme),<\/li>\n<li>Maliyeti y\u00fcksek (fazla say\u0131da veritaban\u0131\/sunucu),<\/li>\n<li>Otomasyon gereksinimi a\u011f\u0131r (provisioning, migration, versiyonlama)<\/li>\n<\/ul>\n<p>Multi\u2011tenant model ise tam tersine:<\/p>\n<ul>\n<li>Kaynaklar\u0131 payla\u015ft\u0131rarak maliyeti azalt\u0131r,<\/li>\n<li>Schema migration ve s\u00fcr\u00fcm g\u00fcncellemelerini tek yerden y\u00fcr\u00fctmenizi sa\u011flar,<\/li>\n<li>Basit bir MVP\u2019den y\u00fczlerce m\u00fc\u015fteriye do\u011fru b\u00fcy\u00fcmeyi daha y\u00f6netilebilir k\u0131lar.<\/li>\n<\/ul>\n<p>Elbette her \u00e7ok kirac\u0131l\u0131 mimari ayn\u0131 de\u011fil. K\u00fc\u00e7\u00fck SaaS ve API projeleri i\u00e7in do\u011fru modeli se\u00e7ebilmek ad\u0131na \u00f6nce temel t\u00fcrleri netle\u015ftirelim.<\/p>\n<h2><span id=\"MultiTenant_Veritabani_Mimarisi_Turleri\">Multi\u2011Tenant Veritaban\u0131 Mimarisi T\u00fcrleri<\/span><\/h2>\n<h3><span id=\"1_Tek_Veritabani_Ortak_Sema_Shared_DB_Shared_Schema\">1) Tek Veritaban\u0131, Ortak \u015eema (Shared DB, Shared Schema)<\/span><\/h3>\n<p>En basit ve en s\u0131k kullan\u0131lan modeldir. T\u00fcm m\u00fc\u015fterilerin verisi ayn\u0131 veritaban\u0131ndaki ayn\u0131 tablolar\u0131 payla\u015f\u0131r. Ayr\u0131m\u0131 sa\u011flamak i\u00e7in her tabloya bir <code>tenant_id<\/code> veya <code>company_id<\/code> alan\u0131 eklersiniz.<\/p>\n<p>\u00d6rnek tablo yap\u0131s\u0131:<\/p>\n<ul>\n<li><code>users(id, tenant_id, name, email, ...)<\/code><\/li>\n<li><code>invoices(id, tenant_id, amount, status, ...)<\/code><\/li>\n<\/ul>\n<p>Avantajlar\u0131:<\/p>\n<ul>\n<li><strong>Basitlik:<\/strong> Tek \u015fema, tek migration seti, tek ba\u011flant\u0131 stringi.<\/li>\n<li><strong>D\u00fc\u015f\u00fck maliyet:<\/strong> K\u00fc\u00e7\u00fck bir <a href=\"https:\/\/www.dchost.com\/tr\/vps\">VPS<\/a> veya orta seviye bir veritaban\u0131 sunucusu bile uzun s\u00fcre yeter.<\/li>\n<li><strong>Merkezi raporlama:<\/strong> T\u00fcm m\u00fc\u015fterileri kapsayan toplu raporlar yazmak \u00e7ok kolay.<\/li>\n<\/ul>\n<p>Dezavantajlar\u0131:<\/p>\n<ul>\n<li><strong>\u0130zolasyon:<\/strong> Kod taraf\u0131nda <code>tenant_id<\/code> filtrelerini atlamak, yanl\u0131\u015f join\u2019ler yapmak veri s\u0131z\u0131nt\u0131s\u0131na yol a\u00e7abilir.<\/li>\n<li><strong>Migration riski:<\/strong> Hatal\u0131 bir migration t\u00fcm m\u00fc\u015fterileri ayn\u0131 anda etkiler.<\/li>\n<li><strong>\u00c7ok b\u00fcy\u00fck tenant\u2019lar:<\/strong> Bir m\u00fc\u015fterinin devasa verisi, di\u011fer t\u00fcm m\u00fc\u015fterilerin performans\u0131n\u0131 etkileyebilir.<\/li>\n<\/ul>\n<p>K\u00fc\u00e7\u00fck SaaS ve API projelerinde MVP a\u015famas\u0131nda en \u00e7ok tercih etti\u011fimiz model budur. ISO 27001 gibi a\u011f\u0131r uyumluluk gereklilikleri yoksa ve tek bir \u00fclkede, orta \u00f6l\u00e7ekli i\u015fletmelere hizmet veriyorsan\u0131z bu yakla\u015f\u0131m uzun s\u00fcre i\u015f g\u00f6r\u00fcr.<\/p>\n<h3><span id=\"2_Tek_Veritabani_Ayri_Sema_Shared_DB_Isolated_Schema\">2) Tek Veritaban\u0131, Ayr\u0131 \u015eema (Shared DB, Isolated Schema)<\/span><\/h3>\n<p>Bu modelde t\u00fcm m\u00fc\u015fteriler ayn\u0131 veritaban\u0131n\u0131 payla\u015f\u0131r ama her m\u00fc\u015fterinin kendi \u015femas\u0131 (schema) vard\u0131r. \u00d6rne\u011fin:<\/p>\n<ul>\n<li><code>tenant_123.users<\/code><\/li>\n<li><code>tenant_456.users<\/code><\/li>\n<\/ul>\n<p>Avantajlar\u0131:<\/p>\n<ul>\n<li><strong>Daha iyi izolasyon:<\/strong> Yanl\u0131\u015fl\u0131kla tenant_123 ile tenant_456 verisini kar\u0131\u015ft\u0131rmak daha zordur, \u00e7\u00fcnk\u00fc tamamen farkl\u0131 \u015femalardad\u0131r.<\/li>\n<li><strong>Schema varyasyonlar\u0131:<\/strong> Baz\u0131 b\u00fcy\u00fck m\u00fc\u015fteriler i\u00e7in tablo yap\u0131s\u0131n\u0131 hafif\u00e7e \u00f6zelle\u015ftirmeniz gerekti\u011finde esneklik sa\u011flar.<\/li>\n<\/ul>\n<p>Dezavantajlar\u0131:<\/p>\n<ul>\n<li><strong>Schema y\u00f6netimi:<\/strong> Her tenant i\u00e7in migration uygulaman\u0131z gerekir; bu da otomasyon ihtiyac\u0131n\u0131 art\u0131r\u0131r.<\/li>\n<li><strong>\u00c7o\u011falma:<\/strong> 500 m\u00fc\u015fteri \u2192 her tabloda 500 kopya anlam\u0131na gelir; y\u00f6netimsel karma\u015f\u0131kl\u0131k h\u0131zla artar.<\/li>\n<\/ul>\n<p>K\u00fc\u00e7\u00fck SaaS\u2019lerde bu model genellikle &#8220;ortak \u015fema&#8221; modelini a\u015f\u0131p, ama her m\u00fc\u015fteri i\u00e7in ayr\u0131 veritaban\u0131na ge\u00e7meden \u00f6nceki ara basamak olarak d\u00fc\u015f\u00fcn\u00fcl\u00fcr. \u00c7ok m\u00fc\u015fterili bir CRM\/ERP tarz\u0131 \u00fcr\u00fcnde birka\u00e7 kurumsal m\u00fc\u015fteriyi \u00f6zelle\u015ftirmek i\u00e7in tercih edilebilir.<\/p>\n<h3><span id=\"3_Her_Musteriye_Ayri_Veritabani_Database_per_Tenant\">3) Her M\u00fc\u015fteriye Ayr\u0131 Veritaban\u0131 (Database per Tenant)<\/span><\/h3>\n<p>Burada her m\u00fc\u015fteri i\u00e7in tamamen ayr\u0131 bir veritaban\u0131 (hatta bazen ayr\u0131 sunucu) a\u00e7ars\u0131n\u0131z. \u00d6rne\u011fin:<\/p>\n<ul>\n<li><code>db_customer_1<\/code><\/li>\n<li><code>db_customer_2<\/code><\/li>\n<\/ul>\n<p>Avantajlar\u0131:<\/p>\n<ul>\n<li><strong>G\u00fc\u00e7l\u00fc izolasyon:<\/strong> Bir veritaban\u0131 \u00e7\u00f6kerse ya da migration\u2019da sorun ya\u015farsa, sadece o m\u00fc\u015fteri etkilenir.<\/li>\n<li><strong>Farkl\u0131 SLA\u2019ler:<\/strong> B\u00fcy\u00fck m\u00fc\u015fterilere farkl\u0131 yedekleme, replikasyon, donan\u0131m ve bak\u0131m pencereleri sunabilirsiniz.<\/li>\n<li><strong>Kolay ta\u015f\u0131ma:<\/strong> \u0130steyen m\u00fc\u015fterinin veritaban\u0131n\u0131 al\u0131p kendi altyap\u0131s\u0131na ta\u015f\u0131mas\u0131 daha pratik olabilir.<\/li>\n<\/ul>\n<p>Dezavantajlar\u0131:<\/p>\n<ul>\n<li><strong>Operasyonel y\u00fck:<\/strong> Migration, \u015fema versiyonlama, izleme ve yedekleme s\u00fcre\u00e7leri \u00e7ok kirac\u0131l\u0131 shared modellerden daha karma\u015f\u0131k hale gelir.<\/li>\n<li><strong>Maliyet:<\/strong> \u00c7ok say\u0131da k\u00fc\u00e7\u00fck veritaban\u0131, ba\u011flant\u0131 say\u0131lar\u0131 ve bak\u0131m g\u00f6revleri i\u00e7in ek kaynak ister.<\/li>\n<\/ul>\n<p>K\u00fc\u00e7\u00fck SaaS ve API projelerinde bu mimariyi genellikle yaln\u0131zca <strong>\u00e7ok b\u00fcy\u00fck veya regulasyona tabi birka\u00e7 \u00f6zel m\u00fc\u015fteri<\/strong> i\u00e7in kullanmay\u0131 \u00f6neriyoruz. Geri kalan kitle ortak veritaban\u0131nda tutulup, se\u00e7ili m\u00fc\u015fterilere &#8220;dedicated veritaban\u0131&#8221; opsiyonu sunmak dengeli bir \u00e7\u00f6z\u00fcmd\u00fcr.<\/p>\n<h3><span id=\"4_Hibrit_Modeller_Buyukler_Ayri_Kucukler_Ortak\">4) Hibrit Modeller: B\u00fcy\u00fckler Ayr\u0131, K\u00fc\u00e7\u00fckler Ortak<\/span><\/h3>\n<p>Ger\u00e7ek hayatta \u00e7o\u011fu SaaS \u00fcr\u00fcn\u00fc tek bir modele s\u0131k\u0131\u015fmak zorunda kalmaz. \u00d6rne\u011fin:<\/p>\n<ul>\n<li>Standart paket m\u00fc\u015fterileri: Ortak veritaban\u0131 + ortak \u015fema.<\/li>\n<li>Kurumsal paket m\u00fc\u015fterileri: Ayr\u0131 veritaban\u0131 veya ayr\u0131 \u015fema.<\/li>\n<\/ul>\n<p>B\u00f6ylece:<\/p>\n<ul>\n<li>Erken a\u015famada tek veritaban\u0131 ile h\u0131z ve maliyet avantaj\u0131 kazan\u0131rs\u0131n\u0131z,<\/li>\n<li>B\u00fcy\u00fcd\u00fck\u00e7e problem \u00e7\u0131karan veya ayr\u0131 SLA isteyen m\u00fc\u015fterileri kademeli olarak ay\u0131r\u0131rs\u0131n\u0131z.<\/li>\n<\/ul>\n<p>Hibrit yakla\u015f\u0131m\u0131 kurgularken, ileride ta\u015f\u0131ma operasyonlar\u0131n\u0131 da d\u00fc\u015f\u00fcnmek gerekir. \u00d6zellikle ortak veritaban\u0131ndaki belirli bir tenant\u2019\u0131 al\u0131p ayr\u0131 bir veritaban\u0131na ta\u015f\u0131mak i\u00e7in kimlik alanlar\u0131, foreign key yap\u0131lar\u0131 ve tutarl\u0131 bir yedek stratejiniz olmal\u0131d\u0131r.<\/p>\n<h2><span id=\"Kucuk_SaaS_ve_API_Projeleri_Icin_Dogru_Mimarinin_Secimi\">K\u00fc\u00e7\u00fck SaaS ve API Projeleri \u0130\u00e7in Do\u011fru Mimarinin Se\u00e7imi<\/span><\/h2>\n<p>Teoride mimari t\u00fcrlerini bilmek yeterli de\u011fil; hangi a\u015famada hangi modeli se\u00e7meniz gerekti\u011fini netle\u015ftirmek kritik. Daha \u00f6nce <a href=\"https:\/\/www.dchost.com\/blog\/kucuk-saas-uygulamalari-icin-en-dogru-hosting-mimarisi-tek-vps-coklu-vps-ve-yonetilen-bulut\/\">k\u00fc\u00e7\u00fck SaaS uygulamalar\u0131 i\u00e7in do\u011fru hosting mimarisini se\u00e7meye odaklanan yaz\u0131m\u0131zda<\/a> altyap\u0131 perspektifini anlatt\u0131k; burada veritaban\u0131 taraf\u0131yla birle\u015ftirelim.<\/p>\n<h3><span id=\"Asama_1_MVP_ve_Ilk_1020_Musteri\">A\u015fama 1: MVP ve \u0130lk 10\u201320 M\u00fc\u015fteri<\/span><\/h3>\n<ul>\n<li><strong>\u00d6nerilen veritaban\u0131 modeli:<\/strong> Tek veritaban\u0131, ortak \u015fema (shared schema).<\/li>\n<li><strong>Hedef:<\/strong> H\u0131zl\u0131 geli\u015ftirme, minimum operasyonel y\u00fck.<\/li>\n<li><strong>Tipik kullan\u0131m:<\/strong> SaaS faturalama, basit CRM, k\u00fc\u00e7\u00fck \u00f6l\u00e7ekte raporlama paneli, webhook t\u00fcketen API\u2019ler.<\/li>\n<\/ul>\n<p>Bu a\u015famada karma\u015f\u0131k \u015fema varyasyonlar\u0131 ya da per-tenant veritaban\u0131 genellikle gereksizdir. \u00d6nemli olan:<\/p>\n<ul>\n<li>T\u00fcm tablolarda <strong>tutarl\u0131 bir <code>tenant_id<\/code> alan\u0131<\/strong> olmas\u0131,<\/li>\n<li>SQL sorgular\u0131n\u0131n <strong>her zaman tenant filtresiyle<\/strong> yaz\u0131lmas\u0131,<\/li>\n<li>Index\u2019lerin tenant bazl\u0131 sorgular\u0131 destekleyecek \u015fekilde tasarlanmas\u0131d\u0131r.<\/li>\n<\/ul>\n<h3><span id=\"Asama_2_50200_Musteri_ve_Artan_Yuk\">A\u015fama 2: 50\u2013200 M\u00fc\u015fteri ve Artan Y\u00fck<\/span><\/h3>\n<p>Bu noktada baz\u0131 m\u00fc\u015fteriler:<\/p>\n<ul>\n<li>Daha yo\u011fun kullan\u0131m yapmaya,<\/li>\n<li>Di\u011ferlerinden \u00e7ok daha fazla veri \u00fcretmeye,<\/li>\n<li>Daha sert SLA ve performans beklentileriyle gelmeye<\/li>\n<\/ul>\n<p>ba\u015flar.<\/p>\n<p>Bu a\u015famada:<\/p>\n<ul>\n<li>Genel kitle i\u00e7in yine tek veritaban\u0131 + ortak \u015fema kullan\u0131labilir.<\/li>\n<li>\u00c7ok b\u00fcy\u00fck veya reg\u00fclasyonlu birka\u00e7 m\u00fc\u015fteri i\u00e7in <strong>ayr\u0131 veritaban\u0131<\/strong> veya <strong>ayr\u0131 \u015fema<\/strong> opsiyonu sunulabilir.<\/li>\n<\/ul>\n<p>Burada \u00f6nemli olan, kod taban\u0131n\u0131n ba\u015ftan per\u2011tenant ba\u011flant\u0131 ya da &#8220;tenant context&#8221; kavram\u0131na haz\u0131rlanm\u0131\u015f olmas\u0131d\u0131r. \u00d6rne\u011fin:<\/p>\n<ul>\n<li>Node.js\u2019te <code>request<\/code> context\u2019ine tenant bilgisini en ba\u015fta eklemek,<\/li>\n<li>Laravel\u2019de <strong>global scope<\/strong> veya middleware ile tenant filtreleri uygulamak,<\/li>\n<li>Veritaban\u0131 ba\u011flant\u0131lar\u0131n\u0131 tenant\u2019a g\u00f6re se\u00e7ilebilir k\u0131lmak.<\/li>\n<\/ul>\n<h3><span id=\"Asama_3_Kurumsal_Musteriler_Cografi_Yayilim_ve_Uyumluluk\">A\u015fama 3: Kurumsal M\u00fc\u015fteriler, Co\u011frafi Yay\u0131l\u0131m ve Uyumluluk<\/span><\/h3>\n<p>E\u011fer \u00fcr\u00fcn\u00fcn\u00fcz daha kurumsal segmente a\u00e7\u0131ld\u0131ysa ya da birden fazla \u00fclkede veri bar\u0131nd\u0131rma (veri yerelle\u015ftirme) zorunlulu\u011fu do\u011fduysa, mimariyi \u015fu eksenlerde d\u00fc\u015f\u00fcnmeniz gerekir:<\/p>\n<ul>\n<li>Baz\u0131 m\u00fc\u015fteriler i\u00e7in <strong>tamamen ayr\u0131 veritaban\u0131<\/strong>,<\/li>\n<li>Gerekiyorsa ayr\u0131 <strong>VPS veya dedicated veritaban\u0131 sunucusu<\/strong>,<\/li>\n<li>Co\u011frafi olarak farkl\u0131 veri merkezlerinde (\u00f6rne\u011fin T\u00fcrkiye ve Avrupa) da\u011f\u0131t\u0131k bar\u0131nd\u0131rma.<\/li>\n<\/ul>\n<p>Bu a\u015famada veritaban\u0131 tasar\u0131m\u0131 tek ba\u015f\u0131na yetmez; <strong>replikasyon<\/strong>, <strong>yedekleme<\/strong> ve <strong>felaket kurtarma<\/strong> stratejilerini de birlikte d\u00fc\u015f\u00fcnmek gerekir. DCHost olarak bu t\u00fcr senaryolarda \u00e7o\u011fu zaman veritaban\u0131n\u0131 ayr\u0131 sunuculara ta\u015f\u0131ma, gerekti\u011finde replikalar ekleme ve colocation\/<a href=\"https:\/\/www.dchost.com\/tr\/fiziksel-sunucu\">dedicated sunucu<\/a> kombinasyonlar\u0131 tasarl\u0131yoruz.<\/p>\n<h2><span id=\"Veritabani_Tasarim_Detaylari_Izolasyon_Guvenlik_ve_Performans\">Veritaban\u0131 Tasar\u0131m Detaylar\u0131: \u0130zolasyon, G\u00fcvenlik ve Performans<\/span><\/h2>\n<h3><span id=\"Tenant_Kimligi_ve_Satir_Bazli_Izolasyon\">Tenant Kimli\u011fi ve Sat\u0131r Bazl\u0131 \u0130zolasyon<\/span><\/h3>\n<p>Ortak \u015fema kulland\u0131\u011f\u0131n\u0131zda, her tablonun tenant baz\u0131nda ayr\u0131lmas\u0131 i\u00e7in birka\u00e7 temel prensip hayati \u00f6nem ta\u015f\u0131r:<\/p>\n<ul>\n<li>T\u00fcm i\u015f verisi tablolar\u0131nda <strong>zorunlu <code>tenant_id<\/code> alan\u0131<\/strong> olmal\u0131.<\/li>\n<li><code>tenant_id<\/code> genellikle integer ya da UUID olarak tutulabilir; t\u00fcm tabloda tutarl\u0131 tip kullan\u0131n.<\/li>\n<li>T\u00fcm sorgular, ili\u015fkiler ve join\u2019ler <strong>tenant filtresiyle<\/strong> yaz\u0131lmal\u0131; ORM seviyesinde global filtre kullanmak bu riski azalt\u0131r.<\/li>\n<\/ul>\n<p>PostgreSQL kullan\u0131yorsan\u0131z <strong>Row Level Security (RLS)<\/strong> ile her tenant i\u00e7in otomatik sat\u0131r bazl\u0131 g\u00fcvenlik sa\u011flayabilirsiniz. MySQL\/MariaDB taraf\u0131nda ise genellikle uygulama katman\u0131ndaki filtrelere g\u00fcvenirsiniz; bu y\u00fczden test ve code review s\u00fcre\u00e7lerinde tenant izolasyonu \u00f6zel olarak kontrol edilmelidir.<\/p>\n<h3><span id=\"Index_Tasarimi_tenant_id_Sik_Kullanilan_Alanlar\">Index Tasar\u0131m\u0131: tenant_id + S\u0131k Kullan\u0131lan Alanlar<\/span><\/h3>\n<p>Multi\u2011tenant veritaban\u0131nda index tasarlarken klasik sorgu kal\u0131plar\u0131n\u0131 d\u00fc\u015f\u00fcn\u00fcn:<\/p>\n<ul>\n<li><code>SELECT ... FROM invoices WHERE tenant_id = ? AND created_at &gt; ?<\/code><\/li>\n<li><code>SELECT ... FROM users WHERE tenant_id = ? AND email = ?<\/code><\/li>\n<\/ul>\n<p>Bu sorgular i\u00e7in tipik index desenleri:<\/p>\n<ul>\n<li><code>INDEX invoices_tenant_created_at (tenant_id, created_at)<\/code><\/li>\n<li><code>UNIQUE INDEX users_tenant_email (tenant_id, email)<\/code><\/li>\n<\/ul>\n<p>B\u00f6ylece:<\/p>\n<ul>\n<li>Her tenant\u2019\u0131n verisi index i\u00e7inde gruplan\u0131r,<\/li>\n<li>Hem performans, hem de benzersizlik kontrolleri tenant baz\u0131nda yap\u0131l\u0131r.<\/li>\n<\/ul>\n<p>Ortak veritaban\u0131nda en s\u0131k yap\u0131lan hata, indexleri sadece <code>email<\/code> veya sadece <code>created_at<\/code> gibi alanlara kurup <code>tenant_id<\/code>\u2019yi g\u00f6zden ka\u00e7\u0131rmakt\u0131r. Bu durumda k\u00fc\u00e7\u00fck SaaS projeleri bile birka\u00e7 y\u00fcz bin kay\u0131t sonras\u0131 beklenmedik yava\u015flamalar ya\u015famaya ba\u015flar.<\/p>\n<h3><span id=\"Sema_Degisiklikleri_Migration_ve_Geri_Alma_Stratejisi\">\u015eema De\u011fi\u015fiklikleri (Migration) ve Geri Alma Stratejisi<\/span><\/h3>\n<p>Multi\u2011tenant veritaban\u0131nda her migration, asl\u0131nda t\u00fcm m\u00fc\u015fterilere yans\u0131yacak bir de\u011fi\u015fikliktir. Bu y\u00fczden:<\/p>\n<ul>\n<li>Migration\u2019lar\u0131 \u00f6nce staging ortam\u0131nda, \u00f6rnek tenant verileriyle test edin.<\/li>\n<li>M\u00fcmk\u00fcnse <strong>idempotent<\/strong> ve geri al\u0131nabilir de\u011fi\u015fiklikler yap\u0131n (s\u00fctun drop etmek yerine \u00f6nce kullan\u0131m\u0131n\u0131 sonland\u0131rma gibi).<\/li>\n<li>Canl\u0131da \u00e7al\u0131\u015ft\u0131rmadan \u00f6nce <strong>otomatik yedek al\u0131n<\/strong> ve geri d\u00f6n\u00fc\u015f (rollback) plan\u0131n\u0131z\u0131 yaz\u0131l\u0131 hale getirin.<\/li>\n<\/ul>\n<p>Daha b\u00fcy\u00fck yap\u0131larda MySQL taraf\u0131nda online \u015fema de\u011fi\u015ftirme ara\u00e7lar\u0131 (\u00f6rne\u011fin gh-ost, pt-online-schema-change) hayat kurtarabilir. DCHost altyap\u0131s\u0131nda y\u00fcksek trafik alan veritabanlar\u0131 i\u00e7in bu t\u00fcr ara\u00e7larla neredeyse s\u0131f\u0131r kesintiyle tablo de\u011fi\u015fiklikleri yapan pek \u00e7ok m\u00fc\u015fteri g\u00f6r\u00fcyoruz.<\/p>\n<h3><span id=\"Gizlilik_ve_Uyumluluk_Tenant_Bazli_Yedek_ve_Silme\">Gizlilik ve Uyumluluk: Tenant Bazl\u0131 Yedek ve Silme<\/span><\/h3>\n<p>KVKK\/GDPR gibi reg\u00fclasyonlar s\u00f6z konusuysa, multi\u2011tenant veritaban\u0131nda \u015fu sorulara \u00f6nceden cevap vermeniz gerekir:<\/p>\n<ul>\n<li>Belirli bir tenant\u2019\u0131n verisi talep edildi\u011finde, onu <strong>mant\u0131kl\u0131 s\u00fcrede<\/strong> nas\u0131l silebilirsiniz?<\/li>\n<li>Yedeklerdeki veriler i\u00e7in ne kadar geriye d\u00f6n\u00fck saklama yapacaks\u0131n\u0131z?<\/li>\n<li>Yedeklerden tek bir tenant\u2019\u0131 se\u00e7erek geri d\u00f6nmek m\u00fcmk\u00fcn m\u00fc, yoksa t\u00fcm veritaban\u0131n\u0131 m\u0131 d\u00f6nmeniz gerekiyor?<\/li>\n<\/ul>\n<p>Bu ba\u015fl\u0131k, do\u011frudan \u00e7ok kirac\u0131l\u0131 SaaS veri politikalar\u0131yla ili\u015fkilidir. Detayl\u0131 bir yol haritas\u0131 i\u00e7in <a href=\"https:\/\/www.dchost.com\/blog\/saas-uygulamalari-icin-musteri-verisi-yedekleme-ve-veri-saklama-politikalari\/\">SaaS uygulamalar\u0131nda m\u00fc\u015fteri verisi yedekleme ve veri saklama politikalar\u0131na odaklanan makalemize<\/a> mutlaka g\u00f6z atman\u0131z\u0131 \u00f6neririm.<\/p>\n<h2><span id=\"Hosting_Mimarisi_MultiTenant_Veritabanini_Nereye_Koymali\">Hosting Mimarisi: Multi\u2011Tenant Veritaban\u0131n\u0131 Nereye Koymal\u0131?<\/span><\/h2>\n<p>Veritaban\u0131 modelini netle\u015ftirdikten sonra kritik soru \u015fu: Bu yap\u0131y\u0131 hangi hosting mimarisinde \u00e7al\u0131\u015ft\u0131raca\u011f\u0131z? DCHost olarak s\u0131k\u00e7a g\u00f6rd\u00fc\u011f\u00fcm\u00fcz birka\u00e7 temel desen var.<\/p>\n<h3><span id=\"1_Tek_VPS_Uzerinde_Uygulama_Veritabani\">1) Tek VPS \u00dczerinde Uygulama + Veritaban\u0131<\/span><\/h3>\n<p>K\u00fc\u00e7\u00fck SaaS ve API projeleri i\u00e7in ba\u015flang\u0131\u00e7ta en pratik ve ekonomik model, <strong>tek bir g\u00fc\u00e7l\u00fc VPS<\/strong> \u00fczerinde hem uygulamay\u0131 hem veritaban\u0131n\u0131 bar\u0131nd\u0131rmakt\u0131r. \u00d6zellikle:<\/p>\n<ul>\n<li>Aktif kullan\u0131c\u0131 say\u0131s\u0131n\u0131n d\u00fc\u015f\u00fck oldu\u011fu,<\/li>\n<li>Arka planda yo\u011fun batch i\u015flerin \u00e7al\u0131\u015fmad\u0131\u011f\u0131,<\/li>\n<li>Veri hacminin birka\u00e7 on GB seviyesini ge\u00e7medi\u011fi<\/li>\n<\/ul>\n<p>senaryolarda gayet yeterlidir.<\/p>\n<p>Bu modelde dikkat edilmesi gerekenler:<\/p>\n<ul>\n<li>Veritaban\u0131 i\u00e7in <strong>ayr\u0131 bir disk veya en az\u0131ndan ayr\u0131 bir dizin<\/strong> (\u00f6rne\u011fin NVMe depolama) kullanmak,<\/li>\n<li>Uygulama ve veritaban\u0131 kullan\u0131c\u0131lar\u0131n\u0131 i\u015fletim sistemi seviyesinde ay\u0131rmak,<\/li>\n<li>D\u00fczenli otomatik yedekleri farkl\u0131 bir DCHost sunucusuna veya obje depolama alan\u0131na kopyalamak.<\/li>\n<\/ul>\n<p>Bu yakla\u015f\u0131m, ilk 20\u201350 m\u00fc\u015fteri i\u00e7in genellikle sorunsuz ilerler. Darbo\u011fazlar olu\u015fmaya ba\u015flad\u0131\u011f\u0131nda \u00f6l\u00e7e\u011fi b\u00fcy\u00fctmek yerine, bir sonraki ad\u0131ma ge\u00e7mek daha do\u011frudur.<\/p>\n<h3><span id=\"2_Ayri_Veritabani_Sunucusuna_Gecmek\">2) Ayr\u0131 Veritaban\u0131 Sunucusuna Ge\u00e7mek<\/span><\/h3>\n<p>Uygulama taraf\u0131 CPU a\u011f\u0131rl\u0131kl\u0131 i\u015f yap\u0131yor, veritaban\u0131 da giderek IO a\u011f\u0131rl\u0131kl\u0131 hale geliyorsa, klasik \u00e7\u00f6z\u00fcm <strong>uygulama ve veritaban\u0131n\u0131 farkl\u0131 sunuculara ay\u0131rmakt\u0131r<\/strong>. Bunu do\u011fru zamanlamak i\u00e7in <a href=\"https:\/\/www.dchost.com\/blog\/veritabani-sunucusunu-uygulama-sunucusundan-ayirmak-ne-zaman-mantikli\/\">veritaban\u0131 sunucusunu uygulama sunucusundan ay\u0131rman\u0131n ne zaman mant\u0131kl\u0131 oldu\u011funa dair yaz\u0131m\u0131zda<\/a> detayl\u0131 sinyaller payla\u015fm\u0131\u015ft\u0131k.<\/p>\n<p>Tipik model \u015f\u00f6yle olur:<\/p>\n<ul>\n<li>1 adet DCHost VPS: API\/SaaS uygulamas\u0131, kuyruk i\u015fleri, cron\u2019lar.<\/li>\n<li>1 adet DCHost VPS (daha y\u00fcksek RAM ve NVMe a\u011f\u0131rl\u0131kl\u0131): Sadece veritaban\u0131.<\/li>\n<\/ul>\n<p>Avantajlar\u0131:<\/p>\n<ul>\n<li>Veritaban\u0131n\u0131n CPU, RAM ve disk kaynaklar\u0131n\u0131 ba\u011f\u0131ms\u0131z \u00f6l\u00e7ekleyebilirsiniz.<\/li>\n<li>Bak\u0131m, yedek ve g\u00fcvenlik ayarlar\u0131n\u0131 veritaban\u0131 sunucusunda \u00e7ok daha s\u0131k\u0131 tutabilirsiniz.<\/li>\n<li>Uygulama sunucular\u0131 gerekti\u011finde yatay olarak \u00e7o\u011falt\u0131labilir (load balancer arkas\u0131nda).<\/li>\n<\/ul>\n<h3><span id=\"3_Cok_VPSli_Mimari_Replikasyon_ve_Yuksek_Erisilebilirlik\">3) \u00c7ok VPS\u2019li Mimari, Replikasyon ve Y\u00fcksek Eri\u015filebilirlik<\/span><\/h3>\n<p>M\u00fc\u015fteri say\u0131n\u0131z ve i\u015f kritikli\u011fi artt\u0131k\u00e7a hedef sadece performans de\u011fil, <strong>y\u00fcksek eri\u015filebilirlik<\/strong> olur. Bu noktada:<\/p>\n<ul>\n<li>Bir <strong>primary (yazma)<\/strong> veritaban\u0131,<\/li>\n<li>Bir veya daha fazla <strong>read replica (okuma)<\/strong> veritaban\u0131<\/li>\n<\/ul>\n<p>ile \u00e7al\u0131\u015fan bir mimari kurmak mant\u0131kl\u0131d\u0131r. B\u00f6ylece:<\/p>\n<ul>\n<li>Raporlama ve a\u011f\u0131r SELECT sorgular\u0131n\u0131 replica\u2019lara kayd\u0131rabilirsiniz.<\/li>\n<li>Primary sunucuda sorun \u00e7\u0131kt\u0131\u011f\u0131nda h\u0131zl\u0131ca replica\u2019y\u0131 yeni primary yapacak bir plan\u0131n\u0131z olur.<\/li>\n<\/ul>\n<p>MySQL\/MariaDB veya PostgreSQL taraf\u0131nda temel replikasyon kurulum ad\u0131mlar\u0131n\u0131 ve dikkat etmeniz gereken noktalar\u0131 <a href=\"https:\/\/www.dchost.com\/blog\/mysql-ve-postgresql-replikasyon-kurulumu-ile-vps-uzerinde-yuksek-erisilebilirlik\/\">MySQL ve PostgreSQL replikasyonuyla y\u00fcksek eri\u015filebilirlik kurulumunu anlatt\u0131\u011f\u0131m\u0131z rehberde<\/a> detayl\u0131 \u015fekilde i\u015fledik. Multi\u2011tenant veritaban\u0131 ile birlikte kullan\u0131ld\u0131\u011f\u0131nda, \u00f6zellikle okuma a\u011f\u0131rl\u0131kl\u0131 SaaS panellerinde ciddi nefes ald\u0131r\u0131r.<\/p>\n<h2><span id=\"Operasyonel_Konular_Yedekleme_Deploy_ve_Tenant_Tasima\">Operasyonel Konular: Yedekleme, Deploy ve Tenant Ta\u015f\u0131ma<\/span><\/h2>\n<h3><span id=\"Yedekleme_Stratejisi_Tum_DB_mi_Tenant_Bazli_mi\">Yedekleme Stratejisi: T\u00fcm DB mi, Tenant Bazl\u0131 m\u0131?<\/span><\/h3>\n<p>Multi\u2011tenant veritaban\u0131 i\u00e7in yedekleme stratejisi tasarlarken \u015fu sorular\u0131 mutlaka masaya koyun:<\/p>\n<ul>\n<li>Ka\u00e7 g\u00fcnde bir tam yedek (full backup) alaca\u011f\u0131z?<\/li>\n<li>Aradaki saatlik\/g\u00fcnl\u00fck art\u0131ml\u0131 yedeklerle (incremental) ne kadar veri kayb\u0131n\u0131 tolere edebiliyoruz (RPO)?<\/li>\n<li>Bir hata oldu\u011funda, t\u00fcm veritaban\u0131n\u0131 m\u0131, yoksa tek bir tenant\u2019\u0131 m\u0131 geri getirmemiz gerekiyor?<\/li>\n<\/ul>\n<p>K\u00fc\u00e7\u00fck SaaS projelerinde \u00e7o\u011fu zaman pratik \u00e7\u00f6z\u00fcm:<\/p>\n<ul>\n<li>Belirli periyotlarda tam veritaban\u0131 yede\u011fi,<\/li>\n<li>Olas\u0131 sorunlu migration veya b\u00fcy\u00fck kod da\u011f\u0131t\u0131mlar\u0131ndan hemen \u00f6nce ekstra yedek,<\/li>\n<li>Yedeklerin <strong>farkl\u0131 bir DCHost sunucusunda<\/strong> veya obje depolamada, \u015fifreli ve s\u00fcr\u00fcml\u00fc olarak saklanmas\u0131d\u0131r.<\/li>\n<\/ul>\n<h3><span id=\"ZeroDowntime_Dagitim_ve_Sema_Degisiklikleri\">Zero\u2011Downtime Da\u011f\u0131t\u0131m ve \u015eema De\u011fi\u015fiklikleri<\/span><\/h3>\n<p>Multi\u2011tenant mimaride kod da\u011f\u0131t\u0131m\u0131 ve veritaban\u0131 migration\u2019lar\u0131 \u00e7o\u011fu zaman \u00e7al\u0131\u015fma saatlerine denk gelir; \u00e7\u00fcnk\u00fc m\u00fc\u015fterileriniz farkl\u0131 zaman dilimlerinde veya 7\/24 aktif olabilir. Bu nedenle:<\/p>\n<ul>\n<li>M\u00fcmk\u00fcn oldu\u011funca <strong>geriye uyumlu<\/strong> migration\u2019lar tasarlay\u0131n (\u00f6nce yeni s\u00fctunu ekle, kodu yeni s\u00fctunu kullanacak \u015fekilde g\u00fcncelle, sonra eski s\u00fctunu kald\u0131r).<\/li>\n<li>Uygulama sunucular\u0131nda <strong>blue\u2011green veya rolling deployment<\/strong> kullan\u0131n; b\u00f6ylece k\u0131sa migration s\u00fcrelerinde bile kesinti ya\u015famazs\u0131n\u0131z.<\/li>\n<li>Veritaban\u0131 kilitlenmelerini (lock) azaltmak i\u00e7in b\u00fcy\u00fck tablo de\u011fi\u015fikliklerini d\u00fc\u015f\u00fck trafikli saatlere planlay\u0131n.<\/li>\n<\/ul>\n<h3><span id=\"Belirli_Bir_Tenanti_Tasimak_Ortak_DBden_Ayri_Veritabanina\">Belirli Bir Tenant\u2019\u0131 Ta\u015f\u0131mak: Ortak DB\u2019den Ayr\u0131 Veritaban\u0131na<\/span><\/h3>\n<p>B\u00fcy\u00fcyen SaaS projelerinde s\u0131kl\u0131kla \u015fu senaryo ya\u015fan\u0131r: &#8220;X m\u00fc\u015fterisi \u00e7ok b\u00fcy\u00fcd\u00fc, veritaban\u0131n\u0131 di\u011ferlerinden ay\u0131rmak istiyoruz.&#8221; Bunu ba\u015ftan \u00f6ng\u00f6rmek i\u00e7in:<\/p>\n<ul>\n<li>T\u00fcm ili\u015fkilendirmelerin <code>tenant_id<\/code> \u00fczerinden yap\u0131lmas\u0131na dikkat edin.<\/li>\n<li>Migration ve yedek script\u2019lerinizi <strong>tek bir tenant\u2019\u0131 filtreleyerek export\/import<\/strong> yapabilecek \u015fekilde tasarlay\u0131n.<\/li>\n<li>DNS ve uygulama taraf\u0131nda, belirli tenant\u2019lar i\u00e7in farkl\u0131 veritaban\u0131 ba\u011flant\u0131lar\u0131n\u0131 y\u00f6netebilece\u011finiz bir yap\u0131 kurun.<\/li>\n<\/ul>\n<p>B\u00f6ylece ortak veritaban\u0131nda sorun ya\u015fatmaya ba\u015flayan b\u00fcy\u00fck bir m\u00fc\u015fteriyi ayr\u0131 bir DCHost veritaban\u0131 sunucusuna ta\u015f\u0131mak, g\u00fcnler s\u00fcren bir kabus olmaktan \u00e7\u0131kar; planl\u0131 bir bak\u0131m penceresinde y\u00f6netilebilir hale gelir.<\/p>\n<h2><span id=\"DCHost_Uzerinde_Pratik_Mimari_Onerileri\">DCHost \u00dczerinde Pratik Mimari \u00d6nerileri<\/span><\/h2>\n<p>Teoriyi somutla\u015ft\u0131rmak i\u00e7in DCHost altyap\u0131s\u0131nda s\u0131k g\u00f6rd\u00fc\u011f\u00fcm\u00fcz \u00fc\u00e7 senaryoyu \u00f6zetleyelim.<\/p>\n<h3><span id=\"Senaryo_1_Yeni_Baslayan_Kucuk_SaaS_API_MVP\">Senaryo 1: Yeni Ba\u015flayan K\u00fc\u00e7\u00fck SaaS \/ API (MVP)<\/span><\/h3>\n<ul>\n<li><strong>Veritaban\u0131 modeli:<\/strong> Tek veritaban\u0131, ortak \u015fema.<\/li>\n<li><strong>Hosting:<\/strong> 1 adet DCHost VPS (uygulama + veritaban\u0131 ayn\u0131 sunucuda).<\/li>\n<li><strong>\u00d6nemli noktalar:<\/strong>\n<ul>\n<li>Disk taraf\u0131nda m\u00fcmk\u00fcnse NVMe tercih edin.<\/li>\n<li>G\u00fcnl\u00fck otomatik veritaban\u0131 yede\u011fi al\u0131n, yedekleri farkl\u0131 bir lokasyonda tutun.<\/li>\n<li>Erken a\u015famadan itibaren t\u00fcm sorgular\u0131 <code>tenant_id<\/code> filtresiyle yaz\u0131n.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<h3><span id=\"Senaryo_2_Buyuyen_SaaS_Artan_Trafik_ve_Musteri_Sayisi\">Senaryo 2: B\u00fcy\u00fcyen SaaS, Artan Trafik ve M\u00fc\u015fteri Say\u0131s\u0131<\/span><\/h3>\n<ul>\n<li><strong>Veritaban\u0131 modeli:<\/strong> \u00c7o\u011funluk i\u00e7in ortak \u015fema, birka\u00e7 kurumsal m\u00fc\u015fteri i\u00e7in ayr\u0131 veritaban\u0131.<\/li>\n<li><strong>Hosting:<\/strong>\n<ul>\n<li>1\u20132 adet DCHost VPS (uygulama sunucular\u0131, gerekirse load balancer arkas\u0131nda),<\/li>\n<li>1 adet DCHost VPS (sadece veritaban\u0131, daha y\u00fcksek RAM ve disk IO kapasitesiyle).<\/li>\n<\/ul>\n<\/li>\n<li><strong>\u00d6nemli noktalar:<\/strong>\n<ul>\n<li>ORM veya ba\u011flant\u0131 katman\u0131nda tenant\u2019a g\u00f6re farkl\u0131 veritaban\u0131 se\u00e7ebilecek altyap\u0131 kurun.<\/li>\n<li>Okuma y\u00fck\u00fc artmaya ba\u015flarsa bir read replica eklemeyi planlay\u0131n.<\/li>\n<li>Monitoring (CPU, RAM, disk IO, slow query log) kurulumunu ihmal etmeyin.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<h3><span id=\"Senaryo_3_Kurumsal_Musteriler_ve_Yuksek_Erisilebilirlik\">Senaryo 3: Kurumsal M\u00fc\u015fteriler ve Y\u00fcksek Eri\u015filebilirlik<\/span><\/h3>\n<ul>\n<li><strong>Veritaban\u0131 modeli:<\/strong> B\u00fcy\u00fck m\u00fc\u015fteriler i\u00e7in ayr\u0131 veritaban\u0131, gerekirse ayr\u0131 veritaban\u0131 sunucular\u0131.<\/li>\n<li><strong>Hosting:<\/strong>\n<ul>\n<li>Birden fazla DCHost VPS veya dedicated sunucu (uygulama katman\u0131 i\u00e7in),<\/li>\n<li>Primary + replica veritaban\u0131 sunucular\u0131, gerekiyorsa co\u011frafi olarak farkl\u0131 veri merkezlerinde,<\/li>\n<li>Kritik projeler i\u00e7in DCHost colocation hizmetiyle kendi fiziksel sunucular\u0131n\u0131z\u0131 bar\u0131nd\u0131rma.<\/li>\n<\/ul>\n<\/li>\n<li><strong>\u00d6nemli noktalar:<\/strong>\n<ul>\n<li>Failover senaryolar\u0131n\u0131 d\u00fczenli olarak test edin.<\/li>\n<li>Felaket kurtarma (DR) plan\u0131n\u0131zda RTO\/RPO hedeflerinizi netle\u015ftirin.<\/li>\n<li>Veri yerelle\u015ftirme ve uyumluluk gerekliliklerine g\u00f6re veri merkezi lokasyonunu dikkatle se\u00e7in.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<h2><span id=\"API_Katmani_ve_Rate_Limitingi_Unutmamak\">API Katman\u0131 ve Rate Limiting\u2019i Unutmamak<\/span><\/h2>\n<p>Multi\u2011tenant veritaban\u0131n\u0131z ne kadar iyi olursa olsun, API katman\u0131nda tek bir m\u00fc\u015fterinin t\u00fcm kaynaklar\u0131 t\u00fcketmesini \u00f6nlemezseniz, di\u011fer tenant\u2019lar i\u00e7in de performans d\u00fc\u015fer. Bu y\u00fczden:<\/p>\n<ul>\n<li>Her tenant i\u00e7in <strong>rate limiting<\/strong> (istek say\u0131s\u0131 k\u0131s\u0131tlama) uygulamak,<\/li>\n<li>Arka planda \u00e7al\u0131\u015facak a\u011f\u0131r raporlamalar\u0131 kuyruk sistemine atmak,<\/li>\n<li>API anahtarlar\u0131n\u0131 (API key, token) s\u0131k\u0131 bir \u015fekilde y\u00f6netmek<\/li>\n<\/ul>\n<p>kritik \u00f6nem ta\u015f\u0131r. Bu konuda Nginx ve Redis tabanl\u0131 \u00e7\u00f6z\u00fcmlerle neler yapabilece\u011finizi g\u00f6rmek i\u00e7in <a href=\"https:\/\/www.dchost.com\/blog\/api-ve-mikroservisler-icin-rate-limiting-stratejileri-nginx-cloudflare-ve-redis-ile-trafik-kontrolu\/\">API ve mikroservisler i\u00e7in rate limiting stratejilerini anlatt\u0131\u011f\u0131m\u0131z rehbere<\/a> g\u00f6z atabilirsiniz.<\/p>\n<h2><span id=\"Ozet_ve_Sonraki_Adimlar\">\u00d6zet ve Sonraki Ad\u0131mlar<\/span><\/h2>\n<p>K\u00fc\u00e7\u00fck SaaS ve API projelerinde multi\u2011tenant veritaban\u0131 mimarisini do\u011fru kurgulamak, ilk g\u00fcnden &#8220;enterprise&#8221; karma\u015f\u0131kl\u0131\u011f\u0131na girmek anlam\u0131na gelmiyor. Aksine, basit ama do\u011fru temellerle ba\u015flarsan\u0131z:<\/p>\n<ul>\n<li>Tek VPS \u00fczerinde giderken bile onlarca m\u00fc\u015fteriye rahat\u00e7a hizmet verebilir,<\/li>\n<li>B\u00fcy\u00fcd\u00fck\u00e7e veritaban\u0131n\u0131 ayr\u0131 bir DCHost VPS\u2019e ta\u015f\u0131y\u0131p, replica ekleyerek \u00f6l\u00e7ekleyebilir,<\/li>\n<li>\u00c7ok b\u00fcy\u00fcyen m\u00fc\u015fterileri ayr\u0131 veritabanlar\u0131na ya da dedicated sunuculara sorunsuz bi\u00e7imde ay\u0131rabilirsiniz.<\/li>\n<\/ul>\n<p>Bu yolculukta kritik olan:<\/p>\n<ul>\n<li>Ba\u015fta <strong>do\u011fru multi\u2011tenant modeli<\/strong> se\u00e7mek (genelde ortak \u015fema ile ba\u015flamak),<\/li>\n<li><strong>tenant_id odakl\u0131 tasar\u0131m<\/strong> ve sa\u011flam index\u2019ler kurmak,<\/li>\n<li>Yedekleme, replikasyon ve felaket kurtarma planlar\u0131n\u0131 ka\u011f\u0131t \u00fczerinde de\u011fil, ger\u00e7ek testlerle do\u011frulamakt\u0131r.<\/li>\n<\/ul>\n<p>E\u011fer &#8220;Bizim SaaS \u015fu an 20 m\u00fc\u015fteride, ama 200\u2019e gitti\u011fimizde ne olacak?&#8221; sorusunu kafan\u0131zdan atmak istiyorsan\u0131z, mevcut yap\u0131n\u0131z\u0131 birlikte de\u011ferlendirebiliriz. DCHost olarak veritaban\u0131 mimarisi, VPS\/dedicated plan se\u00e7imi ve colocation senaryolar\u0131nda hem teknik hem operasyonel tarafta yan\u0131n\u0131zday\u0131z.<\/p>\n<p>\u00c7ok kirac\u0131l\u0131 mimarinizi ve hosting altyap\u0131n\u0131z\u0131 birlikte planlamak i\u00e7in, DCHost destek ekibine projeyi k\u0131saca \u00f6zetleyen bir mesaj g\u00f6ndermeniz yeterli. Mevcut durumu, b\u00fcy\u00fcme hedeflerinizi ve regulasyon gerekliliklerinizi bilmemiz, sizin i\u00e7in en dengeli multi\u2011tenant veritaban\u0131 ve hosting mimarisini tasarlamam\u0131z i\u00e7in fazlas\u0131yla yeterli olacakt\u0131r.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>\u0130&ccedil;indekiler1 K\u00fc\u00e7\u00fck SaaS ve API Projelerinde Multi\u2011Tenant Veritaban\u0131 Neden Kritik?2 Multi\u2011Tenant Veritaban\u0131 Nedir, Tekil Mimardan Fark\u0131 Ne?3 Multi\u2011Tenant Veritaban\u0131 Mimarisi T\u00fcrleri3.1 1) Tek Veritaban\u0131, Ortak \u015eema (Shared DB, Shared Schema)3.2 2) Tek Veritaban\u0131, Ayr\u0131 \u015eema (Shared DB, Isolated Schema)3.3 3) Her M\u00fc\u015fteriye Ayr\u0131 Veritaban\u0131 (Database per Tenant)3.4 4) Hibrit Modeller: B\u00fcy\u00fckler Ayr\u0131, K\u00fc\u00e7\u00fckler Ortak4 K\u00fc\u00e7\u00fck [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":4471,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26],"tags":[],"class_list":["post-4470","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-teknoloji"],"_links":{"self":[{"href":"https:\/\/www.dchost.com\/blog\/wp-json\/wp\/v2\/posts\/4470","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dchost.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dchost.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/wp-json\/wp\/v2\/comments?post=4470"}],"version-history":[{"count":0,"href":"https:\/\/www.dchost.com\/blog\/wp-json\/wp\/v2\/posts\/4470\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/wp-json\/wp\/v2\/media\/4471"}],"wp:attachment":[{"href":"https:\/\/www.dchost.com\/blog\/wp-json\/wp\/v2\/media?parent=4470"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/wp-json\/wp\/v2\/categories?post=4470"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/wp-json\/wp\/v2\/tags?post=4470"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}