# Database

> Create PostgreSQL databases for your projects, connect them to your environments and download their backups. Connection details are passed to your app automatically.

Turguz offers PostgreSQL 17. A **database server** is a PostgreSQL instance used only by your tenant. Every environment connected to it gets its own database inside it; environments can't see each other's data. Connection details are passed to your app as environment variables, so you don't need to write anything by hand.

Servers and their connections are on the **Veritabanı** (Database) page; an environment's database is on that environment's **Veritabanı** (Database) tab.

## The shortest way: adding a database to an environment

**Open the environment's database tab**

On the **Projeler** (Projects) page, select the environment and switch to the **Veritabanı** (Database) tab.
**«Veritabanı ekle» (Add database)**

If you don't have a database server yet, a server of the smallest size is created automatically and counted against your quota. If you have more than one server, you're asked which one to connect to.
**Pass it to your app**

The card says «Bir adım kaldı» (One step left): press the «Şimdi uygula» (Apply now) button so your app sees the new connection.

If you're setting up the project with «Kur ve dağıt» (Set up and deploy), the «PostgreSQL kullanıyor — yeni bir veritabanı oluştur ve bağla» (Uses PostgreSQL — create and connect a new database) option on the setup screen does the same thing as one step of the setup.

## Variables passed to your app

The details of the connected database are passed to your app in these variables: `DATABASE_URL`, `PGHOST`, `PGPORT`, `PGUSER`, `PGPASSWORD`, `PGDATABASE`, `PGSSLMODE`, `ConnectionStrings__DefaultConnection`, `DIRECT_URL`, `POSTGRES_URL`, `POSTGRES_PRISMA_URL`, `DB_HOST`, `DB_PORT`, `DB_USER`, `DB_PASSWORD`, `DB_NAME`, `SPRING_DATASOURCE_URL`, `SPRING_DATASOURCE_USERNAME`, `SPRING_DATASOURCE_PASSWORD`, `POSTGRES_HOST`, `POSTGRES_PORT`, `POSTGRES_DB`, `POSTGRES_USER`, `POSTGRES_PASSWORD`, `QUARKUS_DATASOURCE_DB_KIND`, `QUARKUS_DATASOURCE_JDBC_URL`, `QUARKUS_DATASOURCE_USERNAME`, `QUARKUS_DATASOURCE_PASSWORD`, `DB_DATABASE`, `DATABASE_USER`, `DATABASE_USERNAME`, `DATABASE_PASSWORD`, `JDBC_DATABASE_URL`, `JDBC_DATABASE_USERNAME`, `JDBC_DATABASE_PASSWORD`, `DATABASE_HOST`, `DATABASE_PORT`, `DATABASE_NAME` and `DATABASE_SSL`. Use whichever one your app reads; most frameworks expect `DATABASE_URL`.

If you've defined a variable with the same name yourself, yours takes effect; the panel marks these variables «sizinki geçerli» (yours applies). The password isn't shown in the panel; it's only passed to your app.

The connection can also be encrypted: the database accepts encrypted and unencrypted connections alike. The default is unencrypted (the database is on the same server, in an internal network closed to the outside). If your code asks for an encrypted connection (`?sslmode=require`, `ssl: true`, `ssl: 'require'`), you don't need to do anything else. Node.js apps trust the platform's certificate automatically (`NODE_EXTRA_CA_CERTS`); an environment with a database gets this with its next releases.

These variables aren't passed to the build. If your project generates its pages from the database during the build, turn on **Ayarlar** (Settings) › **Derleme ve çalıştırma** (Build and run) › «Derlemede veritabanı» (Database during build): the build connects with a separate, read-only identity that is valid only for that build. The build can't write to the database; run schema changes in the pre-deploy command, not in the build command. While this setting is on, that command runs before the build, so the build reads up-to-date tables; if the command fails, the build doesn't start. When building with a Dockerfile, the connection variables arrive as `ARG`s (for example `ARG DATABASE_URL`). This setting isn't used when you connect an existing database.

How to run database migrations (schema changes) is explained on the [Environments](/docs/en/ortamlar#yayindan-once-calisan-komut) page.

## Creating a database server

You can also create a server yourself, for example to keep one app's database apart from the others. This isolates failures; it is not a security measure.

On the **Veritabanı** (Database) page, press the «Yeni sunucu aç» (New server) button, fill in «Ad» (Name) and choose the size:

| Size | CPU | Memory | Disk |
| --- | ---: | ---: | ---: |
| «Küçük» (Small) | 1 vCPU | 512 MB | 5 GB |
| «Orta» (Medium) | 1 vCPU | 1 GB | 20 GB |
| «Büyük» (Large) | 2 vCPU | 4 GB | 50 GB |

The size you choose is counted against your quota right away. The size can't be changed later; the disk, however, grows without interruption while the server is running, with «Diski büyüt» (Expand disk). The disk can't be shrunk.

## Connecting one server to several environments

With «+ Ortam bağla» (+ Connect environment) on the server's card, you connect another environment to the same server. After connecting, redeploy that environment so the app sees the variables.

The number of connections a server accepts at the same time is split equally among the environments connected to it. Connecting a new environment also lowers the share of the other environments. If a share would drop below the safe limit, the panel warns you; if the server is full, it doesn't connect the environment and suggests creating a new server.

## Backup and restore

**Warning:**
Turguz doesn't keep a separate backup of your data. Download your backups yourself, regularly.

- «Yedeği indir» (Download backup) downloads a dump of the database to your computer. Because the dump contains all of the data, the backup section is visible only to the «Kiracı yöneticisi» (Tenant admin) and «Geliştirici» (Developer) roles.
- «Yedekten geri yükle» (Restore from backup) uploads a `.sql` dump; the file can be at most 1 GB. Restoring overwrites the existing data. If the operation stops halfway, the database doesn't change at all.

## Connecting with your own tool

**Depends on your installation:** If this feature is not enabled in your installation, it does not appear in the panel; ask your platform admin.

External access depends on installation settings; if it isn't ready, the section says why.

You can read your database from a tool on your computer (such as psql, DBeaver or pgAdmin). In the environment's Database tab, open the **Dışarıdan bağlanma** (External access) section and press «Dışarıdan bağlanmayı aç» (Open external access).

- This connection is **read-only**; it cannot change data. Your app's own connection is not affected.
- You choose who can connect: pick at least one of your **İzinli adresler** (Allowed addresses) lists ([Opening only to specific addresses](/docs/en/internet-erisimi#sitenizi-ve-sunucunuzu-yalniz-belirli-adreslere-acmak)). The «Herkese açık» (Open to everyone) option opens the database to the whole internet; it is confirmed by typing the database name and, while it is on, the card shows a warning. Some installations do not offer this option.
- When you open it, the address, user and **password** are shown. The password is shown only once; save it. If you lose it, «Parolayı yenile» (Renew password) gives a new one and connections opened with the old password are closed.
- The connection is always encrypted. Turn on encryption in your tool (`sslmode=require`); an unencrypted attempt waits a long time and then fails with an unclear error.
- «Kapat» (Close) immediately ends external connections. While the server is stopped or the database is in the trash you cannot connect from outside; access comes back by itself when it runs again.
- Opening, closing, address changes and password renewals are written to the audit log. Only the «Kiracı yöneticisi» (Tenant admin) can change these settings.

## Detaching, deleting and restoring

- **Detaching from an environment:** «Ayır» (Detach) sends the database to the trash. For 7 days you can bring it back, together with its data, with «Geri al» (Restore). «Çöpü boşalt» (Empty trash) deletes it permanently without waiting. «Geri al» (Restore) needs the environment itself: if you delete the environment, the database in the trash can no longer be brought back and is deleted on its own when its time runs out.
- **Deleting it together with the environment:** when you delete an environment that has a database attached, the window shows the database and offers «Veritabanıyla birlikte sil» (Delete with the database). Its data is deleted permanently too; if you want to keep it, take a backup first. The deletion runs in a safe order: the database goes to the trash first, then the environment is deleted, and the trash is emptied last. If the environment can't be deleted, the database stays in the trash and can be brought back with «Geri al» (Restore). If you're connected to an existing database, «Bağlantıyı kaldır ve ortamı sil» (Remove the connection and delete the environment) only removes the connection; the database itself is not touched.
- **Deleting a server:** first detach the databases of the connected environments, then use «Sunucuyu sil» (Delete server). The server waits in quarantine for 7 days and keeps counting against your disk quota during that time. You get a notification 3 days before that time runs out. «Geri al» (Restore) brings the server back; «Kalıcı sil» (Delete permanently) deletes it without waiting and can't be undone.

## Connecting an existing database

You can also connect a PostgreSQL running outside Turguz to an environment. On the environment's **Veritabanı** (Database) tab, press the «Var olan veritabanını bağla» (Connect existing database) button; enter the address, port, database name, user and password, and choose «Onaya gönder» (Submit for approval).

- The connection doesn't work until a platform admin approves it. You get a notification when it's approved.
- The admin can close the access later. Closed access isn't reopened; remove the connection and request it again. The admin's note or reason appears in the notification and on the connection card.
- Only ports 5432 and 6432 can be used.
- Turguz doesn't manage this database: it isn't counted against your quota and Turguz doesn't back it up.
- The password is stored in the environment's secret settings; anyone who can deploy to this environment can access it.

## Vector database

**Depends on your installation:** If this feature is not enabled in your installation, it does not appear in the panel; ask your platform admin.

The vector database (Qdrant) is an installation setting.

If your project does vector search, you can install Qdrant with «Qdrant ekle» (Add Qdrant) on the environment's **Veritabanı** (Database) tab. Sizes:

| Size | CPU | Memory | Disk |
| --- | ---: | ---: | ---: |
| «Küçük» (Small) | 1 vCPU | 1 GB | 5 GB |
| «Orta» (Medium) | 2 vCPU | 2 GB | 10 GB |

Your app is given the `QDRANT_URL`, `QDRANT_HOST` and `QDRANT_PORT` variables, plus `QDRANT_API_KEY` if the access key is enabled.

- You grow it with «Orta boya büyüt» (Upgrade to Medium) and «Diski büyüt» (Expand disk); it can't be shrunk later.
- «Kaldır» (Remove) removes Qdrant; its data is kept for 7 days and comes back with «Geri al» (Restore) during that time. «Verisini kalıcı sil» (Delete its data permanently) deletes it without waiting.
- Turguz doesn't keep a separate backup of Qdrant data either.

## Not supported

The relational database Turguz sets up is PostgreSQL; MySQL, MongoDB and Redis are not offered. A SQLite file on the application's temporary disk is reset with every new version you deploy: keep the file on the application's persistent disk (see [Environment size](/docs/en/ortamlar#ortam-boyu)) or use PostgreSQL.