Most apps rely on their own server code to remember "only show this person their own rows." That's a promise the application has to keep correctly every single time it queries the database. Tenang's database enforces it directly, at the table itself — a bug in the app code can't leak around it. Kebanyakan aplikasi mengandalkan kode servernya sendiri untuk mengingat "hanya tampilkan data milik orang ini." Itu janji yang harus dipenuhi aplikasi dengan benar setiap kali ia mengambil data dari basis data. Basis data Tenang menegakkan itu langsung, di tabelnya sendiri — bug di kode aplikasi tidak bisa membocorkannya.
The database checks your identity, not the app Basis data memeriksa identitasmu, bukan aplikasinya
Your backup row can only be read or written when your signed-in identity matches the row's owner — a rule the database itself checks on every single read and write, not something the application remembers to filter. Even a careless query in the app code still hits that same wall. Baris cadanganmu hanya bisa dibaca atau ditulis kalau identitasmu yang sedang masuk cocok dengan pemilik baris itu — aturan yang diperiksa langsung oleh basis data pada setiap pembacaan dan penulisan, bukan sesuatu yang diingat aplikasi untuk disaring. Bahkan query yang ceroboh di kode aplikasi tetap akan menabrak tembok yang sama.
Even the database owner can't bypass it Bahkan pemilik basis data pun tidak bisa melewatinya
Row-level security can normally be sidestepped by whoever owns the table. Tenang's tables have that bypass explicitly turned off — ownership alone isn't enough to read around the rule; it takes a special, separately-granted permission that isn't handed out. Keamanan tingkat baris biasanya bisa dilewati oleh siapa pun yang memiliki tabel itu. Tabel-tabel Tenang punya jalan pintas itu yang sengaja dimatikan — kepemilikan saja tidak cukup untuk membaca melewati aturan itu; dibutuhkan izin khusus yang diberikan secara terpisah dan tidak dibagikan begitu saja.
The app can't write itself Pro — there's no door for it Aplikasi tidak bisa memberi dirinya sendiri status Pro — tidak ada pintunya
Your Pro/trial status can be read by your own account, but there is no policy that allows a client to write, insert, or update that row at all. It's not that the app chooses not to grant Pro — there's structurally no path for it to. Status Pro/masa cobamu bisa dibaca oleh akunmu sendiri, tapi tidak ada kebijakan yang mengizinkan klien untuk menulis, menambahkan, atau mengubah baris itu sama sekali. Bukan berarti aplikasi memilih untuk tidak memberi status Pro — secara struktural memang tidak ada jalan untuk itu.
Some tables are invisible to any client, period Beberapa tabel sama sekali tidak terlihat oleh klien mana pun
Payment orders, AI usage counters, and raw AI conversation logs have zero client-facing rules at all — not even for a signed-in account reading its own row. The setup script actively deletes any policy that might accidentally expose them and removes direct table access too, so there's no version of the client that could reach them, ever. Pesanan pembayaran, penghitung pemakaian AI, dan log percakapan AI mentah tidak punya aturan yang bisa diakses klien sama sekali — bahkan untuk akun yang sedang masuk membaca barisnya sendiri. Skrip pengaturannya secara aktif menghapus kebijakan apa pun yang bisa saja secara tidak sengaja membuka akses ke sana dan juga mencabut akses langsung ke tabelnya, jadi tidak ada versi klien yang bisa menjangkaunya, kapan pun.