Getting Started with Supabase: Tables, Queries, and Connecting to n8n

The intro article explained what Supabase is and why it sits at the center of the stack. Now we’re going to actually use it. By the end of this article, you’ll have a Supabase project, a real table with proper field types, and a working connection from n8n — including live queries and inserts.

I’m going to use the SendJob data model as the running example throughout. If your use case is different, the mechanics are identical — just swap in your own field names.

---

Creating Your First Project

Go to supabase.com and sign up with GitHub or email. Once you’re in the dashboard, click “New project.”

You’ll need to:

1. Choose an organization (your personal account works fine to start)
2. Name your project — something like sendjob-dev or my-app
3. Set a database password — generate a strong one and store it somewhere safe, you’ll need it later
4. Choose a region — pick the one closest to your users
5. Click “Create new project” and wait about 60 seconds while Supabase provisions everything

When it’s done, you’ll land on the project dashboard. Here’s what each section is:

• Table Editor — a visual interface for creating and browsing tables
• SQL Editor — a query console where you write raw SQL
• Authentication — manage users, providers (email, social, magic link), and auth policies
• Storage — file buckets for images, documents, and other assets
• Edge Functions — serverless TypeScript functions that run at Supabase’s edge
• API Docs — auto-generated documentation for your REST and GraphQL APIs, specific to your schema
• Settings — project URL, API keys, database connection string

Spend five minutes clicking around before you build anything. The layout becomes intuitive fast.

---

The Table Editor vs the SQL Editor

Supabase gives you two ways to work with your database. Both matter, and I recommend learning them in sequence.

Table Editor is the visual interface. You click “New table,” fill in column names and types, and Supabase writes the SQL behind the scenes. It’s good for creating straightforward tables and browsing data. It’s the right place to start.

SQL Editor is where you write actual SQL. It gives you full control — you can create tables with complex constraints, write migration scripts, run ad-hoc queries to debug data issues, and do things the Table Editor can’t handle. Once your schema gets beyond a few simple tables, you’ll spend most of your time here.

My recommendation: start with the Table Editor so the interface doesn’t feel intimidating. Graduate to the SQL Editor as soon as you’re creating your second or third table. Real projects are built in SQL, not through visual editors.

---

Building Your First Table

Let’s create a customers table. Open the Table Editor and click “New table.”

Name it customers. Then add the following columns:

id

• Type: uuid
• Default value: gen_random_uuid()
• Primary key: yes
• This is the unique identifier for every row. UUIDs are better than sequential integers for distributed systems — they don’t expose how many records you have, and they’re safe to generate from multiple sources without collisions.

name

• Type: text
• Not null: yes
• The customer’s full name. Text is the right type for names — no length restriction needed.

email

• Type: text
• Not null: yes
• Unique: yes
• Make it unique so you can’t accidentally create two customer records with the same email address. This constraint enforces data integrity at the database level — not just in your application code.

phone

• Type: text
• Not null: no (allow nulls)
• You might not always have a phone number at the point of record creation. Store phone as text, not a number type — phone numbers have leading zeros, country codes, and formatting characters that numeric types will mangle.

created_at

• Type: timestamptz (timestamp with time zone)
• Default value: now()
• Not null: yes
• Always include a created_at timestamp on every table. Always use timestamptz, not plain timestamp. The difference: timestamptz stores the moment in time independent of time zone. timestamp doesn’t — which means data looks different depending on where you run the query.

Save the table. You’ve just created your first properly structured database table.

---

Row Level Security (RLS)

This is the thing that trips up almost every builder the first time they try to connect n8n to Supabase. Let me save you the hour of debugging.

What Row Level Security is: RLS is a PostgreSQL feature that controls which rows a given user or role can read, insert, update, or delete. It operates at the database level — below your application code — which makes it extremely powerful for security.

Why Supabase enables it by default: Supabase auto-generates a REST API from your schema. If RLS was off by default, anyone who found your API URL and anon key could read or write all your data. Supabase enables RLS by default to prevent accidental data exposure.

The common problem: You create a table, try to insert data from n8n, and get a 403 error or empty results. You’ve done nothing wrong with your n8n setup. RLS is blocking the request because no policies exist yet to allow it.

The solution for server-side automations: Supabase provides two API keys:

• anon key — public-facing. Respects RLS. Use this in browser and mobile clients where you want user-level access controls.
• service role key — private. Bypasses RLS entirely. Use this in server-side automations like n8n, where you’re running trusted backend logic and don’t need row-level restrictions.

For all your n8n → Supabase integrations, use the service role key. It bypasses RLS and just works.

To find both keys: go to your project Settings → API. You’ll see the project URL, the anon key, and the service role key. Copy the service role key somewhere safe — treat it like a password. Anyone with this key has full, unrestricted access to your database.

The advanced article covers writing actual RLS policies for user-facing access. For now: service role key in n8n, and you won’t have RLS problems.

---

The Auto-Generated REST API

This is one of Supabase’s biggest practical advantages. The moment you create a table, Supabase exposes it as a REST endpoint. No routes to write, no controllers, no serializers.

If your project URL is https://abcdefg.supabase.co, then:

• GET https://abcdefg.supabase.co/rest/v1/customers returns all customer rows
• POST https://abcdefg.supabase.co/rest/v1/customers inserts a new customer
• PATCH https://abcdefg.supabase.co/rest/v1/customers?id=eq.{uuid} updates a customer
• DELETE https://abcdefg.supabase.co/rest/v1/customers?id=eq.{uuid} deletes a customer

Every request needs an Authorization: Bearer {key} header with either your anon key or service role key, plus an apikey: {key} header.

The API Docs section of your dashboard shows the exact request format for every table in your schema. Open it and look — it’s genuinely useful.

You can hit this API directly from n8n’s HTTP Request node if you need to, but the Supabase node in n8n handles the credential management for you and is easier to use for standard operations.

---

Connecting from n8n

Setting up the Supabase credential in n8n is straightforward.

In n8n, go to Credentials → New Credential → Supabase. You’ll need two things:

• Project URL — from Supabase Settings → API (looks like https://abcdefg.supabase.co)
• Service Role Key — from the same page (the long key starting with eyJ...)

Save the credential. Now add a Supabase node to a workflow.

Test a SELECT query:

1. Add a Manual Trigger node
2. Add a Supabase node connected to it
3. Set Operation to “Get Many”
4. Set Table to customers
5. Run the workflow

If your credential is set up correctly and your table exists, you’ll see the rows come back (or an empty array if the table is empty — that’s fine).

Test an INSERT:

1. Change the Supabase node Operation to “Create”
2. Set Table to customers
3. Under “Fields to Send,” add:
   • name → Test Customer
   • email → test@example.com
4. Run it

Go to your Supabase Table Editor and check the customers table. Your row should be there.

Mapping dynamic data with expressions: In real workflows, you’re not hardcoding values — you’re mapping data from upstream nodes. In the Supabase node, any field value can be set with an n8n expression using the {{ }} syntax. For example:

• {{ $json.name }} — pulls the name field from the previous node’s output
• {{ $json.body.email }} — pulls email from a webhook payload
• {{ $now.toISO() }} — inserts the current timestamp

This is how n8n workflows pass data through a chain of steps and land it in Supabase with the right values.

---

Basic SQL You Actually Need

You do not need to be a SQL expert to build real things on Supabase. You need five queries. Seriously — five queries cover about 80% of what you’ll ever do in a Supabase + n8n integration.

1. Select all rows:

SELECT * FROM customers;

2. Select with a filter:

SELECT * FROM customers WHERE email = 'test@example.com';

3. Insert a row:

INSERT INTO customers (name, email, phone)
VALUES ('Jane Smith', 'jane@example.com', '+15551234567');

4. Update a row:

UPDATE customers
SET phone = '+15559876543'
WHERE id = 'uuid-goes-here';

5. Delete a row:

DELETE FROM customers WHERE id = 'uuid-goes-here';

That’s the foundation. In SendJob, I also use JOIN regularly — to pull job data together with customer data in a single query. But start with these five. Write them in the SQL Editor to see the results. You’ll understand your data much better after you’ve queried it directly a few times.

One practical thing: the SQL Editor in Supabase runs queries against your live database. Be careful with UPDATE and DELETE statements — they are immediate and there’s no undo. Get comfortable with SELECT first, then move to writes.

---

Viewing and Managing Data

The Table Editor isn’t just for creating tables — it’s also where you browse and manage your data day-to-day.

Browsing rows: Click on a table in the Table Editor to see its rows. You can sort, filter, and search without writing SQL. For quick checks and manual edits, this is much faster than the SQL Editor.

Editing a row: Click on any row to edit it inline. Useful for fixing a bad data entry without writing an UPDATE statement.

Inserting a row manually: The Table Editor has an “Insert row” button. Useful during development when you want to seed some test data without writing INSERT statements.

Exporting as CSV: In the Table Editor, there’s an “Export” option that lets you download the table as a CSV. If you ever need to hand data to someone who works in spreadsheets, this is how.

Supabase Studio: Supabase’s newer dashboard interface (sometimes called Supabase Studio) adds more visual tools — schema visualizations, query history, better filtering. If your dashboard looks slightly different from older screenshots, you’re probably in Studio. The functionality is the same; the layout is cleaner.

One thing the Table Editor can’t do: complex queries with joins, aggregations, or conditional logic. For those, switch to the SQL Editor. But for day-to-day data browsing, the Table Editor is perfectly adequate.

---

Once the basics are solid, Advanced Supabase → covers security policies, database triggers, and edge functions.