Gigalixir’s Standard Tier databases are production level databases. Standard tier databases can grow with your application. Additionally we offer read replicas and high availability.

Creating a Standard Tier Database

To create a standard tier database, run:

gigalixir pg:create --size=$SIZE

Standard tier databases sizes can be 0.6, 1.7, 4, 8, 16, 32, 48, 64, or 96. See Database Pricing for details.

Give it a moment, it takes a few minutes ⏲️ to provision. See Scaling Times for details.

You can check the status by running:

gigalixir pg

The create command will create the DATABASE_URL environment variable if it does not already exist. Additionally if the POOL_SIZE environment variable is not set, this will set it to 9. For more information on properly setting the pool size, see Pool Size Determination.

You can only have one standard tier database per application.

Backups are automatically configured and happen daily. We keep 7 days worth of backups, which can be restored. See Backup and Recovery for more details.

Standard tier databases are created as single instances. High availability can be enabled, see High Availability.

By default, we will create a Postgres 17 database. You can specify any version from Postgres 13 to Postgres 17.

gigalixir pg:create --size=$SIZE --version=POSTGRES_13

See Supported Versions for details.

Listing your Databases

List databases by running:

gigalixir pg

Scaling Your Database

To change the size of your database, run:

gigalixir pg:scale -d $DATABASE_ID --size=$SIZE

Standard tier databases sizes can be 0.6, 1.7, 4, 8, 16, 32, 48, 64, or 96. See Database Pricing for details.

You can find your database ID by running:

gigalixir pg

Scaling will cause a downtime while the database restarts. See Scaling Times for details.

Pool Size Determination

You may also want to adjust your pool_size. We recommend setting the pool size to (M-6)/(n+1) where M is the max connections and n is the num app replicas.

We subtract 6 because Cloud SQL will sometimes - but rarely - use 6 for maintenance purposes.

We use n+1 because rolling deploys will temporarily have an extra replica during the transition.

For example, if you are running a size 0.6 database with 1 app replica, the pool size should be (25-6)/(1+1)=9.

High Availability

Databases are created as single instances. High availability can be enabled with the pg:scale command:

gigalixir pg:scale -d $DATABASE_ID --high_availability=enabled

Scaling will cause a downtime while the database restarts. See Scaling Times for details.

Equally, high availability can be disabled with:

gigalixir pg:scale -d $DATABASE_ID --high_availability=disabled

See High Availability Pricing for cost.

Read Replicas

Read replicas are a great way to improve the performance of your database. Standard databases can have an unlimited number of read replicas.

See Read Replicas for details.

Backup and Recovery

All standard tier databases are automatically backed up daily. We store 7 days worth of backups you can restore to.

See Backup and Recovery for details.

Users and Roles

On the standard tier, your credentials give you administrative privileges to your database. You can create users and roles, grant permissions, create views, etc.

Install a Postgres Extension

First, make sure Google Cloud SQL supports your extension by checking their list of extensions.

Get a psql console into your database:

gigalixir pg:psql

Then, install your extension:

CREATE EXTENSION foo;

Upgrading the Major Version

Minor versions are automatically upgraded during your database’s maintenance window.

New major versions introduce incompatible changes that might require you to modify the application code, the schema, or the database settings. Before you can upgrade your database instance, review the release notes of your target major version to determine the incompatibilities that you must address:

Most extensions work on the upgraded database major version. Drop any extensions that are no longer supported in your target version. For example, drop the chkpass extension if you’re upgrading to PostgreSQL 11 or later versions.

Sometimes, upgrading to PostGIS version 3.1.7 or later can’t complete due to objects using deprecated functions. This can block the upgrade operation. To check the upgrade status, run SELECT PostGIS_full_version();. If there are warnings present, then drop any objects using the deprecated functions and update the PostGIS extension to any intermediate or higher version. After you complete these actions, run the SELECT PostGIS_full_version(); command again. Verify that no warnings appear. Then, proceed with the upgrade operation.

To learn more about upgrading your PostGIS extensions, see Upgrading PostGIS.

To upgrade the major version of your database, run:

gigalixir pg:upgrade -d $DATABASE_ID VERSION

This will start the upgrade process. If you are running any read-replicas, we will first stop the replication. The primary database will be upgraded first, then the replicas.

Versions prior to Postgres 13 must be upgraded to Postgres 13 before upgrading to Postgres 14 or later.

The upgrade process will result in downtime, as the database has to be restarted. The size of the database will determine the length of the upgrade time.

Size Typical Upgrade Time with Read Replicas
0.6 45 - 75 minutes 90 - 150 minutes
1.7 20 - 60 minutes 40 - 120 minutes
4+ 10 - 30 minutes 20 - 60 minutes

Supported Versions

Version Extended Support End-of-life Highest Available Upgrade
POSTGRES_17 2029-12-28 2033-01-01 N/A
POSTGRES_16 2028-12-28 2032-01-01 POSTGRES_17
POSTGRES_15 2027-12-28 2031-01-01 POSTGRES_17
POSTGRES_14 2026-12-28 2030-01-01 POSTGRES_17
POSTGRES_13 2025-12-28 2029-01-01 POSTGRES_17
POSTGRES_12 2024-12-28 2028-01-01 POSTGRES_13
POSTGRES_11 2024-12-28 2028-01-01 POSTGRES_13
POSTGRES_10 2024-12-28 2028-01-01 POSTGRES_13
POSTGRES_9_6 2024-12-28 2028-01-01 POSTGRES_13

Versions in extended support are billed at a higher rate. See Database Pricing for details. When a version reaches end-of-life, it will be automatically upgraded to the next version that is still supported.

Restarting a Standard Database

If you need to restart your database, contact us and we’ll help you out.

Destroying a Standard Database

Warning
Deleting a database also deletes all of its backups. Please make sure you backup your data first. This operation is unrecoverable.

Delete your database by running:

gigalixir pg:destroy -d $DATABASE_ID

Database Pricing

Size Standard
Support		 Extended
Support		 RAM Rollback Days Connection Limit Storage Limit
0.6 $25/mo $50/mo 0.6 GB 7 25 25 GB
1.7 $50/mo $100/mo 1.7 GB 7 50 50 GB
4 $100/mo $200/mo 4 GB 7 100 100 GB
8 $200/mo $400/mo 8 GB 7 200 200 GB
16 $400/mo $800/mo 16 GB 7 250 400 GB
32 $800/mo $1600/mo 32 GB 7 300 800 GB
48 $1200/mo $2400/mo 48 GB 7 350 1.2 TB
64 $1600/mo $3200/mo 64 GB 7 400 1.6 TB
96 $2400/mo $4800/mo 96 GB 7 500 2.4 TB

Prices are prorated to the second.

Sizes 0.6 and 1.7 share CPU with other databases.

All other sizes have dedicated CPU, 1 CPU for every 4 GB of memory.

For example, size 4 has 1 dedicated CPU and size 64 has 16 dedicated CPUs. All databases start with 10 GB disk and increase automatically, as needed.

Contact Us if you are interested in additional sizes.

High Availability Pricing

Adding high availabilty doubles the cost of the database. Prices are prorated to the second. See Database Pricing for the undoubled prices per size.

Scaling Times

Scaling a standard tier database requires a restart of the database. Below is a list of the typical operation times for database sizes.

Size Typical Scaling Time
0.6 10 - 25 minutes
1.7 10 - 25 minutes
4+ 4 - 8 minutes
NEXT ⟶