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_appuser for you
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
Use the Supabase UI
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.
Select the table and create a policy
Find your new table in the Policies page.Create a new policy from scratch.
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.
| Field | Value |
|---|---|
| Policy name | dreamlit_dreamlit_app_select_policy |
| Command / action | SELECT |
| Target role | dreamlit_app |
| USING expression | true |

Ask your AI
If you use Lovable, Cursor, v0, Bolt, Replit, or another AI assistant, ask it to add the sameSELECT 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
Why can’t Dreamlit read new Supabase tables?
Dreamlit adds a permissiveSELECT 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
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_logor thedreamlitschema, see What if the error mentions the dreamlit schema?
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_logdreamlit.error_logdreamlit.version
Signs this is the issue
- Dreamlit can connect, but publish, resume, or verification fails
- The error mentions
dreamlit.event_logor thedreamlitschema - 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 givedreamlit_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, andDELETEondreamlit.event_logSELECT,INSERT,UPDATE, andDELETEondreamlit.error_logSELECT,INSERT,UPDATE, andDELETEondreamlit.version