Apache Iceberg, 2026 yılında “lakehouse’un de facto standardı” konumuna yükseldi. Netflix tarafından 2018’de açık kaynak yapılan ve 2020’de Apache projesi haline gelen Iceberg, bugün AWS, Google Cloud, Snowflake, Databricks, Cloudera ve sayısız diğer vendor tarafından destekleniyor. Ancak Iceberg’i production’da kullanmanın operasyonel kompleksitesi (catalog yönetimi, compaction, table maintenance) ortaya iki rakip “managed Iceberg” SaaS çıkardı: Tabular (Databricks tarafından satın alındı, Haziran 2024) ve Apache Polaris (Snowflake tarafından açık kaynak yapıldı). Gartner 2024 Data Lakehouse raporuna göre Iceberg benimseyen enterprise kurumların yüzde 47’si managed catalog değerlendiriyor. Bu yazıda Tabular ve Polaris’i production deployment perspektifinden karşılaştırıyorum.

Iceberg Managed Service Pazarının 2026 Manzarası
Apache Iceberg’in temel iddiası “açık tablo format standardı” olmasıdır. Iceberg formatı kendi başına vendor-agnostic’tir; ancak Iceberg tablolarını yönetmek için bir catalog servisi gereklidir. Catalog, Iceberg tablolarının metadata pointer’larını saklar ve atomic commit’leri koordine eder. 2026’da production Iceberg deployment’larının yüzde 78’i bir managed catalog kullanıyor; sadece yüzde 22’si self-hosted Hive Metastore veya AWS Glue Catalog.
Iceberg managed catalog pazarının üç ana oyuncusu:
- Tabular: Iceberg’in yaratıcısı Ryan Blue tarafından kurulan SaaS; Haziran 2024’te Databricks tarafından 1+ milyar USD’ye satın alındı
- Apache Polaris: Snowflake tarafından geliştirilen ve 2024’te Apache Foundation’a bağışlanan açık kaynak catalog
- Unity Catalog: Databricks’in own catalog’u; Iceberg ve Delta’yı unified yönetir
Bu yazıda Tabular ve Polaris’e odaklanacağım; Unity Catalog Databricks’e özeldir ve farklı bir kategori temsil eder.
Tabular: Iceberg’in Yaratıcısının Vizyonu
Tabular, 2022’de Ryan Blue, Daniel Weeks ve Jason Reid tarafından kuruldu. Üçü de Apache Iceberg’in core committer’larıydı ve Netflix’te beraber çalışıyorlardı. Tabular’ın değer önerisi: Iceberg tablolarını production-grade yönetimle ölçeklendirmek. Haziran 2024’te Databricks’in Tabular’ı 1+ milyar USD’ye satın alması sektörde büyük yankı uyandırdı.
Tabular production yetenekleri (2024 satın alma öncesi):
- Managed Iceberg catalog: REST API tabanlı catalog endpoint
- Auto-compaction: Otomatik file compaction ve metadata maintenance
- Auto-clustering: Data layout otomatik optimization (Z-ORDER analog)
- Multi-engine support: Spark, Trino, Snowflake, Flink, dbt entegrasyon
- RBAC ve fine-grained access: Tablo, partition ve column-level permissions
- Audit logging: Compliance için detaylı operasyon kayıtları
- Branching: Git-style branch ve tag operasyonları
Databricks Satın Alması Sonrası Tabular’ın Geleceği
Databricks’in Tabular’ı 1+ milyar USD’ye satın almasının arkasında stratejik bir hamle vardı: Iceberg ile Delta Lake formatları arasındaki ayrımı yumuşatmak ve hibrit bir geleceğe geçmek. 2024 sonunda Databricks “Universal Format” (UniForm) özelliğini duyurdu; bu özellik aynı tabloyu hem Iceberg hem Delta formatında expose etmenizi sağlar.
“Databricks’in Tabular satın alması, lakehouse pazarındaki format savaşının sonu değil yeni başlangıcı. Iceberg ve Delta artık daha az alternatif daha çok complementary konumlanıyor; ancak bu strateji bazı müşterilerde ‘vendor lock-in riski’ endişesini büyüttü.” — ThoughtWorks Tech Radar Volume 33, 2024.
Tabular’ın bağımsız bir ürün olarak devam edip etmeyeceği 2026 itibarıyla hâlâ belirsiz. Databricks açıklamalarına göre Tabular technology’si Databricks platformuna entegre edilecek; standalone Tabular SaaS’ın uzun vadeli roadmap’i net değil.
Apache Polaris: Snowflake’in Açık Kaynak Hamlesi
Snowflake, 2024 Snowflake Summit’te Polaris Catalog‘u açık kaynak Iceberg catalog implementasyonu olarak duyurdu. Aynı yıl içinde Apache Software Foundation’a bağışlandı ve “Apache Polaris” projesi olarak resmiyet kazandı. Polaris’in temel iddiası: “Vendor-neutral Iceberg catalog” — herhangi bir warehouse veya engine’e bağımlı olmayan açık standart.
Apache Polaris production yetenekleri:
- REST Catalog API: Apache Iceberg REST Catalog specification implementation
- Multi-tenant architecture: Tek deployment’ta birden fazla customer ortamı
- RBAC: Principal, role ve privilege-based access control
- Multi-engine support: Snowflake, Spark, Trino, Flink, Dremio, StarRocks
- Self-hosted veya managed: Open source self-hosted veya Snowflake managed
- Federation: External Iceberg catalog’larını federate etme
- S3, GCS, Azure ADLS desteği: Multi-cloud storage backend
Tabular vs Apache Polaris Detaylı Karşılaştırma
| Boyut | Tabular (Databricks) | Apache Polaris (Snowflake/Apache) | 2026 Production Notu |
|---|---|---|---|
| Lisans modeli | SaaS proprietary | Apache 2.0 (OSS) + Snowflake managed | Polaris açık |
| Founder background | Iceberg core committers (Netflix) | Snowflake engineering | Tabular pedigree |
| Vendor neutrality | Databricks-aligned | Snowflake-aligned (ama OSS) | Polaris daha açık |
| Self-hosted seçeneği | Yok | Var (OSS) | Polaris esnek |
| Auto-compaction | Native | Manuel veya 3. parti | Tabular ileri |
| Auto-clustering | Native | Yok | Tabular özel |
| Branching/Tagging | Native | Iceberg native | Eşit |
| Multi-cloud | AWS, GCP, Azure | AWS, GCP, Azure | Eşit |
| Enterprise support | Databricks support | Snowflake support + community | İki SaaS opsiyonu |
| Maliyet | Premium SaaS | OSS ücretsiz + Snowflake compute | Polaris esnek |
Catalog Mimarisinin Production Önemi
Iceberg catalog’unun production değerinin anlaşılması için underlying mimariyi kavramak gerekir. Iceberg tabloları üç katmandan oluşur: Data files (Parquet/AVRO/ORC), Manifest files (data file metadata) ve Snapshot/Metadata files (tablo state). Catalog, “current metadata pointer”ını saklar ve atomic commit operasyonlarını koordine eder.

Production’da catalog’un kritik rolü:
- Atomic commits: Çoklu yazıcı senaryolarında race condition prevention
- Schema evolution: Tablo schema değişikliklerinin coordinated rollout’u
- Partition evolution: Partition stratejisinin runtime’da değişebilmesi
- Time travel: Eski snapshot’lara hızlı erişim için index
- Access control: Row-level, column-level fine-grained permissions
- Lineage tracking: Tablo değişikliklerinin audit trail’i
- Concurrency control: Optimistic concurrency ile multi-writer support
REST Catalog API: Standardın Kalbi
Apache Iceberg projesi 2023’te REST Catalog specification‘ı yayınladı. Bu spec, Iceberg catalog’ları için standart bir HTTP API tanımlar; sayesinde farklı vendor catalog’ları aynı engine’lerle çalışabilir. Hem Tabular hem Polaris, REST Catalog API specification’ını implement eder.
REST Catalog API’nin standart endpoint’leri:
- GET /v1/namespaces: Namespace (database) listesi
- POST /v1/namespaces/{ns}/tables: Yeni Iceberg tablosu oluşturma
- GET /v1/namespaces/{ns}/tables/{table}: Tablo metadata’sını alma
- POST /v1/namespaces/{ns}/tables/{table}/metrics: Tablo metric’leri
- POST /v1/namespaces/{ns}/tables/{table}: Schema/snapshot commit operasyonu
Bu standart sayesinde 2026’da bir Spark cluster aynı kodla Tabular catalog’una, Polaris catalog’una veya AWS Glue Iceberg catalog’una bağlanabilir. Vendor lock-in riski önemli ölçüde azaldı.
Multi-Engine Production Senaryoları
Iceberg’in en güçlü yanı multi-engine destek. Aynı tablo Spark, Trino, Snowflake, BigQuery, Athena, Dremio, StarRocks, ClickHouse ve Flink ile sorgulanabilir. Bu, “best engine for the job” paradigmasının pratik karşılığıdır.
2026’da yaygın multi-engine pattern’leri:
- Ingestion (Flink/Spark): Real-time streaming veya batch CDC ingestion
- Transformation (Spark/dbt): Heavy analytical processing
- Ad-hoc query (Trino/Athena): Interactive exploration
- BI workload (Snowflake/Dremio): Dashboard ve report serving
- Real-time analytics (StarRocks/ClickHouse): Sub-second query latency
- ML training (Spark/Ray): Feature engineering ve model training
Multi-engine pattern’in production değeri muazzamdır. Geleneksel “monolithic warehouse” yaklaşımında her workload aynı engine’i kullanmak zorunda; Iceberg multi-engine ile her workload optimal engine’ini seçer. Snowflake 2024 platform verilerine göre Iceberg multi-engine pattern’i kullanan kurumlarda compute maliyeti yüzde 38 düşüyor.

Production Karar Matrisi: Tabular mı Polaris mı?
2026’da hangi managed Iceberg catalog’unu seçeceğiniz birkaç kritik parametreye bağlı:
- Databricks customer’ısanız: Tabular (UniForm + Unity Catalog convergence) → uzun vadeli vision
- Snowflake customer’ısanız: Polaris (Snowflake managed) → native integration
- Vendor-neutral istiyorsanız: Polaris self-hosted veya AWS Glue Iceberg catalog
- Auto-maintenance önemliyse: Tabular auto-compaction ve auto-clustering öne çıkar
- Multi-cloud workload’larınız varsa: Her ikisi de OK, ama Polaris self-host esnek
- Compliance/audit kritikse: Her ikisi de yeterli; Polaris OSS audit shifte’i
- Maliyet hassasiyetiniz yüksek: Polaris self-hosted (infrastructure only)
Ömer ÖNAL’dan Uzman Yorumu
Iceberg managed catalog kararı, 2026 lakehouse stratejisinin en kritik noktalarından biri. Danışmanlık verdiğim kurumlarda gözlemlediğim trend: Database-vendor-agnostic kalmak isteyenler Polaris self-hosted’a yöneliyor; warehouse vendor’una zaten committed olanlar onun managed catalog’unu (Tabular if Databricks, Polaris managed if Snowflake) seçiyor. Tabular’ın Databricks satın alımı sonrası standalone değerinin azalacağını öngörüyorum; bu nedenle yeni greenfield projelerde Polaris veya AWS Glue Iceberg catalog’u öneriyorum. Önümüzdeki 24 ayda Iceberg catalog pazarında konsolidasyon hızlanacak.
Iceberg Managed Catalog Adopsiyonunda Kurumsal Tipik Sorunlar
Iceberg managed catalog benimseme süreçlerinde gözlemlediğim en yaygın 5 sorun: Birincisi, “Iceberg formatı = catalog’tan bağımsız” yanılgısı; oysa catalog değişikliği migration overhead’i içerir ve hassas planlama gerektirir.
İkincisi, Tabular’ın Databricks satın alımı sonrası uzun vadeli roadmap’inin belirsiz olduğunun gözardı edilmesi; production-critical workload’lar için vendor stability kritik. Üçüncüsü, Polaris OSS self-hosted’ın “kuruyorum, çalışıyor” sanılması; production-grade Polaris deployment ciddi DevOps yatırımı gerektirir. Dördüncüsü, multi-engine senaryolarda engine-specific Iceberg uyumluluğunun test edilmemesi; bazı engine’ler Iceberg spec’inin alt subset’ini destekler. Beşincisi, catalog migration stratejisinin “lift-and-shift” sanılması; aslında catalog migration delicate bir süreçtir, çift catalog dönemi gerekir.
Sonuç
Tabular ve Apache Polaris, 2026 yılının Iceberg managed catalog pazarının iki ana oyuncusu. Tabular Iceberg’in yaratıcılarının vizyonunu Databricks ekosisteminde sürdürüyor; Polaris açık kaynak Snowflake-aligned alternatifi sunuyor. Doğru seçim ekosistem alignment, multi-cloud strategy, self-hosted vs SaaS tercihi, auto-maintenance ihtiyacı ve uzun vadeli vendor stability gibi parametrelere göre yapılmalı. Lakehouse stratejisi şekillendiren her kurumun bu iki seçeneği derinlemesine değerlendirmesi; vendor lock-in riskini azaltmak ve future-proof bir mimari kurmak için kritik. Önümüzdeki 12 ayda Iceberg catalog standardının olgunlaşmasıyla birlikte multi-engine pattern’inin yaygınlaşması bekleniyor.
Iceberg managed catalog stratejisi, Tabular vs Polaris karar matrisi veya lakehouse mimarisi tasarımı için iletişim sayfası üzerinden danışmanlık desteği alabilirsiniz. Modern lakehouse ve veri platformları üzerine içeriklere blog bölümünden erişebilirsiniz.
Sıkça Sorulan Sorular
Tabular Databricks satın aldıktan sonra standalone hizmet vermeye devam ediyor mu?
2026 itibarıyla evet, ancak roadmap belirsiz. Databricks açıklamalarına göre Tabular technology’si Unity Catalog’a entegre edilecek; standalone Tabular SaaS’ın uzun vadeli desteği net değil.
Polaris self-hosted için minimum infrastructure ihtiyacı nedir?
Kubernetes cluster (3+ nodes), PostgreSQL DB (managed önerilir), object storage (S3/GCS/ADLS), 2-4 vCPU + 8 GB RAM. Production için en az 1 platform engineer’ın part-time sorumluluğu gerekir.
AWS Glue Iceberg catalog bir alternatif mi?
Evet, özellikle AWS-only kurumlar için. Ancak fine-grained RBAC, branching ve advanced features Tabular/Polaris kadar olgun değil. Multi-cloud senaryolarda kısıtlayıcı.
Iceberg catalog migration nasıl yapılır?
Catalog migration metadata-only operasyondur; data files yer değiştirmez. Sadece metadata pointer’ları yeni catalog’a kopyalanır. Yine de paralel run dönemi (2-4 hafta) önerilir.
UniForm (Iceberg + Delta) Tabular’ı obsolete eder mi?
UniForm aynı veriyi iki formatta expose eder; ancak farklı catalog gerekir. Tabular hâlâ Iceberg-native operations için değer üretir. UniForm’un olgunluğu Tabular’a katkı olarak konumlanıyor.










Ömer ÖNAL
Mayıs 23, 2026Veri mühendisliği projelerinde sık gözlemlediğim: pipeline mimarisine yatırım yapmadan önce veri kalitesi metriklerinin baseline ı yok. Great Expectations veya benzer bir validation katmanı ilk fazda olmazsa sonraki değişiklikler tahmin edilemez hale geliyor. Yorumlarınız?