--- title: "How TIR DBaaS works" description: "What a TIR DBaaS database is made of, how clients reach it through the IP allowlist or a VPC, and what snapshots, parameter groups, and statuses do." content_type: "concept" product: "tir-dbaas" platform: "TIR" url: "/tir/tir-dbaas/concepts/how-tir-dbaas-works/" topic: ["how-it-works"] --- # How TIR DBaaS works A TIR DBaaS database is a managed PostgreSQL server that runs in your TIR project in Chennai. TIR sets it up from the choices you make when you create it, gives it an address to connect to, and lets you take snapshots, add storage, and tune its settings from the portal. ## What a database is made of Every database you create has one node, the primary, which runs PostgreSQL. **Nodes & Monitoring** lists it with the role **Primary**. Four things make up the database: - **The PostgreSQL version.** You choose it when you create the database. - **The compute plan.** The plan gives the database its vCPU and memory. - **The disk.** It holds the operating system as well as your data, so less than the full size is free for data. The disk is 20 GB to 1,000 GB. You can increase it later from **Edit** while the database keeps serving connections, and the larger size is permanent. - **The admin user.** The username and password you set on the create page are the first login to the database. You can change the password with **Reset Password** while the database is **Running**. Every new database also has a database named `defaultdb`, owned by the admin user. The connection details in the portal point to `defaultdb`, and the extensions you choose are installed there. The name, plan, PostgreSQL version, and admin username are set once, when you create the database, and stay the same for its life. To see every choice on the create page, read [Create a database](/tir/tir-dbaas/how-to/create-a-database/). ## How clients reach the database Clients reach a database in one of two ways. **The public endpoint** is an address and port on the internet, shown as **Public Endpoint** on the **Overview** tab. The port is 5432. Only the IPv4 addresses and CIDR ranges in the database's **IP Allowlist** can reach it, so you add the address of every computer or server that connects. The allowlist holds up to 50 ranges and needs at least one. The range `0.0.0.0/0` lets any IPv4 address in; use it only for short tests. The public endpoint opens once the database is **Running**. **The VPC address** is the primary's address on a TIR VPC, shown as **Private Endpoint** when a VPC is attached. VMs and services in that VPC connect to it privately, and the IP allowlist applies only to the public endpoint. TIR attaches a VPC chosen on the create page after the launch, once the database turns **Running**. To change either one, see [Control network access](/tir/tir-dbaas/how-to/control-network-access/). ## Every connection uses SSL Every connection from outside the database must use SSL and a password. The database accepts only encrypted logins over the network. **SSL** on the **Overview** tab reads **Required**, and the connection URL the portal gives you ends in `sslmode=require`. For the strings and snippets, see [Connect to a database](/tir/tir-dbaas/how-to/connect-to-a-database/). ## Snapshots A snapshot is a copy of the primary's disk. You can take one at any time while the database is **Running**, and the database stays online while it is taken. A schedule can take snapshots for you every 6 hours, daily, weekly, or on your own cron expression. It keeps the number of scheduled snapshots you choose, from 1 to 60. Restoring a snapshot creates a new database with the source's plan, PostgreSQL version, and storage size. The source database stays as it is. When you delete a database, its snapshots go with it: they leave the list, and you can restore them only before the delete. See [Take a snapshot](/tir/tir-dbaas/how-to/take-a-snapshot/), [Schedule snapshots](/tir/tir-dbaas/how-to/schedule-snapshots/), and [Restore a database from a snapshot](/tir/tir-dbaas/how-to/restore-from-a-snapshot/). ## Parameter groups and extensions A parameter group is a named set of PostgreSQL parameter values for one PostgreSQL version. You create it under **Databases** > **Parameter Groups**, and one group can be attached to many databases of that version. A database uses at most one group. Attaching a group applies its values while the database keeps running, and values that PostgreSQL reads only when it starts take effect at the next restart. See [Use parameter groups](/tir/tir-dbaas/how-to/use-parameter-groups/). Extensions add features to PostgreSQL, such as vector search with pgvector or fuzzy text search with pg_trgm. pg_stat_statements and vector are chosen for you on the create page, and you can add more later. Adding an extension leaves the database running. An installed extension stays installed, because the portal can only add extensions. See [Add extensions](/tir/tir-dbaas/how-to/add-extensions/). ## Statuses The status shows on the list and at the top of the database's page. - **Creating**: a new or restored database is being set up. A database that is starting or restarting also shows **Creating** until it is back. - **Running**: the database is up and accepting connections. **Edit** and **Create Snapshot** are available only in this status. - **Scaling**: a storage increase is under way. - **Stopped**: the database has been stopped, and its storage is kept. - **Terminating**: the database is being deleted. - **Failed**: a launch, start, restart, or delete failed, or the database stopped accepting connections after a storage increase. For what to do, see [Troubleshooting TIR DBaaS](/tir/tir-dbaas/troubleshooting/tir-dbaas/). For how a database is charged, see [Billing for TIR DBaaS](/tir/tir-dbaas/concepts/billing-options/).