> For the complete documentation index, see [llms.txt](https://docs.tryterra.co/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.tryterra.co/help-center/help-topics/webhook/storage-destinations-s3-sqs-supabase-sql-gcs/sql-destination-schema-setup.md).

# How do I set up a Postgres SQL destination?

Terra creates the SQL destination tables itself, in the default schema of the database user you provide.

The [SQL destination](https://docs.tryterra.co/unified-api/integration-setup/setting-up-data-destinations/sql-database-postgres-mysql) needs no tables created in advance. **Terra creates `terra_users`, `terra_data_payloads` and `terra_other_payloads` automatically** on delivery if they don't exist, and recreates them if they are dropped.

There is no dedicated `terra` schema. The tables go in the **default schema of the database user** you give Terra, usually `public`. To keep them apart from your own tables, use a database user whose default schema is one you choose.

That user needs permission to create tables in its default schema, and to insert into, update and delete from those tables.

Set the **Scheme** field to the database type, `postgres` or `mysql`. It is not a schema name, and any other value makes delivery fail.

`reference_id` is stored in the users table; join it on `user_id` to associate data with your internal users.

{% hint style="info" %}
Updated payloads (for example revised dailies) are inserted as **new rows** with a new `created_at` rather than overwriting, since there is no unique constraint. Deduplicate downstream.
{% endhint %}