Supabase'ın 30 Ekim değişikliği: yeni tablolar erişilebilir olmak için açık GRANT gerektirecek

30 Ekim 2026'da Supabase, tüm mevcut projelerde bir izin değişikliğini zorunlu kılacak: public şemasında oluşturulan tablolar, biri erişimi açıkça GRANT ile tanımlayana kadar Data API üzerinden erişilebilir olmayacak. Data API, supabase-js ve diğer istemci kütüphanelerinin çağırdığı REST ve GraphQL katmanıdır; dolayısıyla daha önce oluşturulduğu anda çalışan bir tablo, artık bir GRANT ifadesi çalıştırılana kadar uygulamadan görünmez kalacak. Zaman çizelgesi ve çözümler, VibeTierList tarafından Supabase'ın changelog kayıtları ve dokümantasyonuna dayanarak dev.to'da yayımlanan bir yazıda açıklanıyor; yazar, değişikliğin canlı bir projede test edilmediğini belirtiyor.

Neler değişiyor

Şimdiye kadar Supabase, anon, authenticated ve service_role rollerine her yeni public şema tablosunda select, insert, update ve delete ayrıcalıklarını otomatik olarak veriyordu; bu da her tabloyu /rest/v1/ ve /graphql/v1/ üzerinden anında kullanılabilir kılıyordu. Yeni davranışta bu ayrıcalıklar, bir migration bunları ekleyene kadar hiç yok sayılacak.

Yazının Supabase changelog'undan aktardığı zaman çizelgesine göre dağıtım aşamalı ilerledi: 28 Nisan 2026'dan itibaren proje oluşturulurken isteğe bağlı (opt-in), 30 Mayıs 2026'dan itibaren yeni projelerde varsayılan ve 30 Ekim 2026'dan itibaren tüm mevcut projelerde zorunlu olacak.

Supabase'ın açıkladığı gerekçe AI tarafından üretilen kod: agent'lar, CLI betikleri ve uygulama oluşturma platformları artık tabloları bir insanın incelemesi olmadan oluşturuyor ve eski varsayılan, güvenliği sağlanmadan önce bir tabloyu görünür kılmayı kolaylaştırıyordu.

Kimler etkileniyor

Yazıya göre, bir uygulama Data API üzerinden public tabloları okuyup yazıyorsa ya da migration'ları veya AI kodlama aracı GRANT ifadeleri olmadan tablo oluşturuyorsa harekete geçmek gerekiyor. Bu, Lovable veya Bolt gibi AI oluşturucularla derlenen Supabase uygulamalarının çoğunu tanımlıyor; bu uygulamalarda tarayıcı doğrudan REST endpoint'ini çağırıyor ve şemayı araç yazıyor.

Supabase'a göre etkilenmeyenler: mevcut tablolar ayrıcalıklarını koruyor ve erişilebilir kalıyor, satır düzeyinde güvenlik (row-level security) önceki gibi davranıyor, storage, auth, realtime ve özel şemalara dokunulmuyor ve doğrudan Postgres bağlantısı kullanan uygulamalar hiçbir fark görmüyor.

Yazının dikkat çektiği açık sorulardan biri, Lovable Cloud ve Bolt Database gibi yönetilen Supabase uyumlu backend'lerin değişikliği aynı tarihte uygulayıp uygulamayacağı ya da grant'ları kendilerinin ekleyip eklemeyeceği. Oluşturucuyu kendi Supabase projesine yönlendiren herkes bunun geçerli olduğunu varsaymalı.

Arızayı nasıl tanıyabilirsiniz

Belirgin işaret, yepyeni bir tablo üzerine kurulu bir özelliğin yüklenememesi ya da kaydedememesi, buna karşılık eski özelliklerin çalışmaya devam etmesidir. Yazıda alıntılanan Supabase sorun giderme dokümantasyonuna göre istemciler bunu genellikle 401 veya 403 olarak bildiriyor; tarayıcının ağ panelinde başarısız REST isteğini incelemek, eksik rol ve ayrıcalığı adlandıran bir ipucuyla birlikte tablo için izin reddedildi anlamına gelen Postgres 42501 hatasını ortaya çıkarıyor.

Bir benzer durumu da elemek gerekiyor: satır düzeyinde güvenlik ihlalleri de 42501 döndürür, ancak iletileri bir row-level security politikasından söz eder. Bu, RLS'nin işini yapmasıdır, bu değişiklik değil. Supabase'ın Security Advisor'ı önerilen SQL ile birlikte etkilenen tabloları işaretliyor, Table Editor bir Data API görünürlük rozeti gösteriyor ve mevcut grant'lar SQL editöründe information_schema.role_table_grants sorgulanarak listelenebilir.

Çözüm

Supabase'ın önerisi, tabloyu, grant'larını, satır düzeyinde güvenlik ayarını ve politikalarını tek bir migration içinde bir arada tutmaktır: her role yalnızca uygulamanın ihtiyaç duyduğunu verin — genellikle authenticated ve service_role için select, insert, update ve delete; anon için yalnızca oturum açmamış ziyaretçilerin tabloyu okuması amaçlanmışsa select — ardından satır düzeyinde güvenliği etkinleştirin ve politikaları ekleyin. GRANT olmadan Postgres, sorguyu RLS'ye hiç danışılmadan reddeder.

Yazı üç kestirme karşı uyarıyor: anon'a bilinçli public okuma tabloları için değil de refleksle grant vermek; grant'ları güvenlik olarak görmek, çünkü grant'lar bir rolün tabloya erişip erişemeyeceğini belirlerken RLS hangi satırları göreceğini belirler; ve şemanın tamamına tek seferde grant vermek, çünkü bu, RLS'nin hiç etkinleştirilmediği tabloları da görünür kılardı. AI oluşturucu iş akışları için Supabase, aracın system prompt'unu güncellemeyi ya da agent skill'ini kullanmayı öneriyor; böylece grant'lar varsayılan olarak her yeni tabloyla birlikte gelmiş olur.

Bağlam için: VibeTierList, AI uygulama oluşturucularını test eden bir site işletiyor ve ilgili ücretli bir kontrol satıyor; Supabase'ın yazı için ödeme yapmadığını söylüyor.

Neden önemli

Bu, sakin bir gün gibi görünen bir kırıcı değişiklik. 30 Ekim'in kendisinde hiçbir şey bozulmuyor, çünkü mevcut tablolar grant'larını koruyor; arıza daha sonra, bir AI agent'ı ya da migration'ı bir sonraki tabloyu oluşturduğunda ve kimse GRANT eklemediğinde ortaya çıkıyor. Eski özellikler çalışıp yeni özellik 403 ile ölürken, kimsenin yakından okumadığı üretilmiş kod tabanlarında teşhis edilmesi en zor arıza tam olarak budur. Bu aynı zamanda AI kod üretiminin platformları güvensiz varsayılanlardan vazgeçirmesine somut bir örnek: Supabase bir kolaylığı kaldırıyor, çünkü şemayı artık insanlar değil makineler yazıyor. Lovable, Bolt veya benzer araçlarla Supabase destekli uygulamalar çalıştıran ekipler tarihten önce prompt'larını ve migration şablonlarını güncellemeli ve bu arada satır düzeyinde güvenliğin etkin olup olmadığını da doğrulamalı.