Skip to main content
Created a new Supabase table but Dreamlit can’t read it? The most common cause: Row Level Security (RLS) is enabled on the table but there’s no policy granting dreamlit_app read access yet.

​
This guide assumes

  • You use Supabase Cloud
  • You connected Supabase to Dreamlit using Dreamlit’s Supabase Connect OAuth flow
  • Dreamlit created the dreamlit_app user for you
If you self-host Supabase or connected it as a generic Postgres database, your steps may differ.
This only applies to tables that use RLS, and it’s expected. PostgreSQL doesn’t support default RLS policies for future tables, so each new RLS-enabled table needs its own policy.

​
How do I know if RLS is blocking Dreamlit?

  • You created a new table after connecting Supabase to Dreamlit
  • The table has data in it, but Dreamlit can’t preview any rows
  • You try to publish or configure something in Dreamlit and hit a database access error
Pick the approach that fits your workflow:
  1. Use the Supabase UI
  2. Ask your AI
  3. Use SQL

​
Use the Supabase UI

1

Open the Policies page in Supabase

In Supabase, go to Authentication → Configuration → Policies.If your dashboard uses a slightly different layout, look for Authentication → Policies.
2

Select the table and create a policy

Find your new table in the Policies page.Create a new policy from scratch.
3

Fill the policy to match Dreamlit's setup

Use these values:This mirrors the same policy Dreamlit applies during provisioning. It’s read-only and doesn’t allow inserts, updates, or deletes.If RLS isn’t enabled yet for that table, turn it on first before saving the policy.
Supabase policy editor configured with a SELECT policy for dreamlit_app

Add the Dreamlit read-only policy in the Supabase policy editor

4

Save and retry in Dreamlit

Go back to Dreamlit and retry the action that was failing:
  • Reopen the workflow or table picker
  • Republish the workflow if needed
  • Retry the preview or trigger setup
If the connection is paused, go to Settings → Database Connections and click Resume connection.

​
Ask your AI

If you use Lovable, Cursor, v0, Bolt, Replit, or another AI assistant, ask it to add the same SELECT policy for dreamlit_app.

​
Use SQL

If you’d rather paste SQL into Supabase SQL Editor, use this builder.

​
Check it worked

In Supabase, open the table’s Policies view and confirm you can see a policy with:
  • name dreamlit_dreamlit_app_select_policy
  • command SELECT
  • target role dreamlit_app
Then go back to Dreamlit and retry the action.

​
Why can’t Dreamlit read new Supabase tables?

Dreamlit adds a permissive SELECT policy for dreamlit_app when it provisions your Supabase connection, but that only covers tables that exist at that moment. New tables need the same policy added manually. Supabase encourages RLS, and tables created through the dashboard often start with RLS enabled by default. How a table is created affects whether RLS is on:
  • Tables created in the Supabase dashboard usually have RLS enabled by default
  • Tables created via SQL or migrations need RLS enabled manually
For more background, see Supabase’s Row Level Security guide and Hardening the Data API.

​
What if the table is still not visible?

If Dreamlit still can’t read the table after adding the policy:
  • Check the table name: make sure you used the correct schema and table name
  • Verify RLS is on: make sure RLS is enabled on the table you added the policy to
  • Test without RLS: temporarily disable RLS on that table to see if Dreamlit starts working
  • Check for schema errors: if the error mentions dreamlit.event_log or the dreamlit schema, see What if the error mentions the dreamlit schema?
If Dreamlit works once RLS is disabled, the issue is with the table’s RLS configuration rather than the Dreamlit connection itself.

​
What if the error mentions the dreamlit schema?

Sometimes the issue isn’t your application table. RLS was turned on for Dreamlit’s own internal tables:
  • dreamlit.event_log
  • dreamlit.error_log
  • dreamlit.version
Dreamlit needs full access to those internal tables to run correctly.

​
Signs this is the issue

  • Dreamlit can connect, but publish, resume, or verification fails
  • The error mentions dreamlit.event_log or the dreamlit schema
  • Disabling RLS on your application table didn’t help

​
Disable RLS on Dreamlit’s internal tables

Disable RLS on Dreamlit’s internal tables: After that, retry the action in Dreamlit.

​
If you need to keep RLS on those tables

Add explicit RLS policies that give dreamlit_app the access it needs, or ask your AI to make that change for you. If you keep RLS on Dreamlit’s internal tables, make sure dreamlit_app has these permissions:
  • SELECT, INSERT, UPDATE, and DELETE on dreamlit.event_log
  • SELECT, INSERT, UPDATE, and DELETE on dreamlit.error_log
  • SELECT, INSERT, UPDATE, and DELETE on dreamlit.version