Supabase is now on Postgres 13.3

Summary

New Supabase projects now run on Supabase Postgres 13.3, transitioning the database platform forward from PostgreSQL 12.0. This release introduces features such as native UUID generation with gen_random_uuid, parallel index vacuuming, incremental sorting, smaller btree indexes, and extended statistics improvements. The underlying PostgreSQL binary was built from the ground up to enable Large System Extensions on AWS Graviton2 ARM instances, optimizing locking and synchronization performance. Alongside upgrading the underlying operating system to Ubuntu 20.04 for long-term support through 2025, the team integrated fail2ban to protect direct database connections on ports 5432 and 6543 against brute-force attacks. Finally, Supabase Postgres version numbering now mirrors upstream PostgreSQL major and minor versions to make tracking installed releases easier.

Context

Supabase needed to upgrade from PostgreSQL 12.0 and Ubuntu 18.04 to deliver new database functionality, extend operating system support through 2025, enable Large System Extensions on AWS Graviton2 hardware, and protect database instances from brute-force connection attempts.

Approach / What changed

Supabase built PostgreSQL 13.3 from source to enable LSE support for ARM instances, updated the base operating system to Ubuntu 20.04, aligned repository versioning to track upstream PostgreSQL release numbers, and configured fail2ban on ports 5432 and 6543 to ban IPs for 10 minutes after three failed attempts.

Takeaways

• Supabase Postgres version numbering now mirrors PostgreSQL major and minor releases directly, with patch version bumps applied when releases occur between upstream updates.
• Building PostgreSQL from source enabled Large System Extensions on AWS Graviton2 instances, utilizing atomics to improve locking and synchronization performance.
• Direct database connections on port 5432 for PostgreSQL and port 6543 for PgBouncer are now protected by fail2ban, banning IP addresses for 10 minutes after three failed login attempts.

Related reading

• Supabase · Jul 7, 2020

  Physical vs Logical Backups in PostgreSQL

  PostgreSQL backups fall into two distinct categories: logical backups, which convert data into SQL command files, and physical backups, which copy the underlying file system storage. Logical backups generated with pg_dump or pg_dumpall allow single-database targeting and provide the only practical route for migrating across major Postgres versions with differing internal storage formats. Conversely, physical backups suit larger databases where long-running logical exports can degrade concurrent query performance and risk failure. Physical backups also integrate with Write Ahead Log files through tools like WAL-G to support Point in Time Recovery and minimize Recovery Point Objectives. Selecting between these two strategies depends on whether administrative simplicity, version portability, cluster size, or precise disaster recovery takes precedence.

  Angelico de los Reyes

• Supabase · Nov 27, 2021

  PostgREST 9

  PostgREST 9 introduces several core updates to the tool that turns PostgreSQL databases into RESTful APIs. Developers can now perform inner joins when embedding tables using the !inner keyword, allowing top-level table rows to be filtered directly by embedded table attributes across multiple operators. The release also adds support for POST requests to functions containing a single unnamed parameter, which simplifies handling raw JSON payloads sent by external webhooks. To ensure compatibility with PostgreSQL 14, custom authentication functions accessing HTTP context headers and JWT claims must be updated to parse JSON properties from consolidated settings. Additional enhancements included in this version provide support for partitioned tables alongside documentation improvements and bug fixes.