Tables and Data

Tables are where you store your data.

Tables are similar to excel spreadsheets. They contain columns and rows. For example, this table has 3 "columns" (id, name, description) and 4 "rows" of data:

There are a few important differences from a spreadsheet, but it's a good starting point if you're new to Relational databases.

Creating Tables#

When creating a table, it's best practice to add columns at the same time.

You must define the "data type" of each column when it is created. You can add and remove columns at any time after creating a table.

Supabase provides several options for creating tables. You can use the Dashboard or create them directly using SQL. We provide a SQL editor within the Dashboard, or you can connect to your database and run the SQL queries yourself.

Columns#

You must define the "data type" when you create a column.

Data types#

Every column is a predefined type. PostgreSQL provides many default types, and you can even design your own (or use extensions) if the default types don't fit your needs. You can use any data type that Postgres supports via the SQL editor. We only support a subset of these in the Table Editor in an effort to keep the experience simple for people with less experience with databases.

You can "cast" columns from one type to another, however there can be some incompatibilities between types. For example, if you cast a timestamp to a date, you will lose all the time information that was previously saved.

Primary Keys#

A table can have a "primary key" - a unique identifier for every row of data. A few tips for Primary Keys:

• It's recommended to create a Primary Key for every table in your database.
• You can use any column as a primary key, as long as it is unique for every row.
• It's common to use a uuid type or a numbered identity column as your primary key.

In the example above, we have:

1. created a column called id
2. assigned the data type bigint
3. instructed the database that this should be generated always as identity, which means that Postgres will automatically assign a unique number to this column.
4. Because it's unique, we can also use it as our primary key.

We could also use generated by default as identity, which would allow us to insert our own unique values.

Loading data#

There are several ways to load data in Supabase. You can load data directly into the database or using the APIs. Use the "Bulk Loading" instructions if you are loading large data sets.

Basic data loading#

Bulk data loading#

When inserting large data sets it's best to use PostgreSQL's COPY command. This loads data directly from a file into a table. There are several file formats available for copying data: text, csv, binary, JSON, etc.

For example, if you wanted to load a CSV file into your movies table:

You would connect to your database directly and load the file with the COPY command:

Additionally use the DELIMITER, HEADER and FORMAT options as defined in the PostgreSQL COPY docs.

If you receive an error FATAL: password authentication failed for user "postgres", reset your database password in the Database Settings and try again.

Joining tables with Foreign Keys#

Tables can be "joined" together using Foreign Keys.

This is where the "Relational" naming comes from, as data typically forms some sort of relationship.

In our "movies" example above, we might want to add a "category" for each movie (for example, "Action", or "Documentary"). Let's create a new table called categories and "link" our movies table.

You can also create "many-to-many" relationships by creating a "join" table. For example if you had the following situations:

• You have a list of movies.
• A movie can have several actors.
• An actor can perform in several movies.

Schemas#

Tables belong to schemas. Schemas are a way of organizing your tables, often for security reasons.

If you don't explicitly pass a schema when creating a table, Postgres will assume that you want to create the table in the public schema.

We can create schemas for organizing tables. For example, we might want a private schema which is hidden from our API:

Now we can create tables inside the private schema:

Views#

A View is a convenient shortcut to a query. Creating a view does not involve new tables or data. When run, an underlying query is executed, returning its results to the user.

Say we have the following tables from a database of a university:

students

courses

grades

Creating a view consisting of all the three tables will look like this:

Once done, we can now access the underlying query with:

When to use views#

Views provide the several benefits:

• Simplicity
• Consistency
• Logical Organization
• Security

Simplicity

As a query becomes more complex, it can be a hassle to call it over and over - especially when we run it regularly. In the example above, instead of repeatedly running:

We can run this instead:

Additionally, a view behaves like a typical table. We can safely use it in table JOINs or even create new views using existing views.

Consistency

Views ensure that the likelihood of mistakes decreases when repeatedly executing a query. In our example above, we may decide that we want to exclude the course Introduction to Postgres. The query would become:

Without a view, we would need to go into every dependent query to add the new rule. This would increase in the likelihood of errors and inconsistencies, as well as introducing a lot of effort for a developer. With views, we can alter just the underlying query in the view transcripts. The change will be applied to all applications using this view.

Logical Organization

With views, we can give our query a name. This is extremely useful for teams working with the same database. Instead of guessing what a query is supposed to do, a well-named view can easily explain it. For example, by looking at the name of the view transcripts, we can infer that the underlying query might involve the students, courses, and grades tables.

Security

Views can restrict the amount and type of data presented to a user. Instead of allowing a user direct access to a set of tables, we provide them a view instead. We can prevent them from reading sensitive columns by excluding them from the underlying query.

Materialized Views#

A materialized view is a form of view but it also stores the results to disk. In subsequent reads of a materialized view, the time taken to return its results would be much faster than a conventional view. This is because the data is readily available for a materialized view while the conventional view executes the underlying query each time it is called.

Using our example above, a materialized view can be created like this:

Reading from the materialized view is the same as a conventional view:

Refreshing materialized views#

Unfortunately, there is a trade-off - data in materialized views are not always up to date. We need to refresh it regularly to prevent the data from becoming too stale. To do so:

It's up to you how regularly refresh your materialized views, and it's probably different for each view depending on its use-case.

Materialized views vs Conventional views#

Materialized views are useful when execution times for queries or views are too slow. These could likely occur in views or queries involving multiple tables and billions of rows. When using such a view, however, there should be tolerance towards data being outdated. Some use-cases for materialized views are internal dashboards and analytics.

Creating a materialized view is not a solution to inefficient queries. You should always seek to optimize a slow running query even if you are implementing a materialized view.

Resources#

• Official Docs: Create table
• Official Docs: Create view
• PostgreSQL Tutorial: Create tables
• PostgreSQL Tutorial: Add column
• PostgreSQL Tutorial: Views