Supported Databases

Why Database Connection Details Are Required

SuperAPI requires access to your database to provide its core functionality: intelligent cache invalidation. Unlike traditional caching solutions that rely solely on time-based expiration, SuperAPI monitors changes to your database in real-time, ensuring that cached API responses remain fresh while maximizing cache hit rates.

By connecting directly to your database, SuperAPI can detect data changes at the source, monitoring your database's replication stream to identify exactly when and what data has changed. This enables SuperAPI to perform targeted cache invalidation, selectively invalidating only the affected cache entries. For many changes, SuperAPI can update just portions of cached responses rather than invalidating them entirely.

This approach captures all data changes, including those made by cron jobs, batch processes, direct database modifications, and other operations that bypass your API layer. This database-level monitoring is what enables SuperAPI to make traditionally "uncacheable" APIs cacheable, dramatically improving performance without compromising data freshness.

Supported Database Types and Hosts

SuperAPI currently supports Postgres, MySQL & MongoDB out of the box:

Amazon RDS (Managed PostgreSQL instances in AWS)
Google Cloud SQL for PostgreSQL (Managed PostgreSQL instances in GCP)

Additional database types and hosting options will be added in future releases. If you need support for other database types, please contact the SuperAPI team at hello@trysuperapi.com.

Enabling Logical Replication

Before adding your database to SuperAPI, you must ensure that logical replication is enabled. This is a prerequisite because SuperAPI relies on logical replication to monitor database changes.

For Amazon RDS PostgreSQL

To enable logical replication on your RDS PostgreSQL instance:

Create a custom parameter group in the RDS console if you don't already have one
Modify the parameter group to set rds.logical_replication to 1
Apply the parameter group to your RDS instance
Reboot your instance for the changes to take effect

For a detailed, step-by-step guide with screenshots, you can follow this tutorial: Create an RDS Parameter Group and enabling Logical Replication for the RDS Instance

For Google Cloud SQL PostgreSQL

To enable logical replication on your Cloud SQL PostgreSQL instance:

Navigate to your Cloud SQL instance in the Google Cloud Console
Go to the 'Customize' tab in your instance settings
Enable the 'cloudsql.logical_decoding' flag
Set the flag value to 'on'
Save your changes and restart the instance

For a visual guide with detailed steps, refer to: Enable Logical Decoding in Cloud SQL

These configuration changes are essential for SuperAPI to connect to your database's replication stream. Without logical replication enabled, SuperAPI will not be able to monitor data changes and provide its intelligent cache invalidation capabilities.

How SuperAPI Monitors Your Database

SuperAPI creates a dedicated database user and configures a replication system to monitor your data changes in real-time. This enables precise cache invalidation without slowing down your database or affecting your application's operations.

Creating a Specialized Database Reader

When you add a database, SuperAPI creates a dedicated superapi_user with read-only access:

-- Create the SuperAPI user
CREATE USER superapi_user LOGIN PASSWORD 'secure_password';
GRANT pg_read_all_stats, pg_monitor, rds_replication TO superapi_user;
 
-- Grant SELECT permissions on your chosen tables
GRANT SELECT ON public.logs, public.person, public.candidate_to_sourcing_context;
 
-- Bypass Row Level Security if needed
ALTER USER superapi_user BYPASSRLS;

This user can only read data and monitor changes—it never performs writes to your database. The BYPASSRLS setting ensures SuperAPI can see all data changes regardless of security policies, which is essential for complete cache invalidation.

The Three-Part Change Detection System

After creating the user, SuperAPI configures a replication system with three key components working together:

1. Publication: Acts as a filter that broadcasts changes only for your selected tables:

CREATE PUBLICATION superapi_publication;
ALTER PUBLICATION superapi_publication ADD TABLE table1, table2, table3;

2. Replication Slot: Creates a persistent channel that ensures SuperAPI never misses changes:

3. Table Configuration: Ensures complete change information is available:

ALTER TABLE your_table REPLICA IDENTITY FULL;

This integrated system allows SuperAPI to identify which cache entries are affected by data changes and perform surgical cache updates rather than wholesale invalidation. The result is consistently fresh data with minimal origin server load.

From Database Tables to Smart API Caching

The tables you select during database configuration become available when configuring endpoints in SuperAPI. This mapping enables precise cache invalidation rules based on data dependencies.

When configuring endpoints, you'll define which database tables affect which API responses, ensuring optimal performance while maintaining data freshness.

Troubleshooting Database Connections

When connecting your database to SuperAPI, you might encounter some challenges. Here are common issues and their solutions:

Network connectivity issues Ensure that SuperAPI can reach your database on the specified port and that any necessary firewall rules or security groups are configured correctly.

Permission problems Verify that the database user you've provided has sufficient permissions to create the SuperAPI user and replication components.

Replication configuration Check your database settings:

The wal_level parameter must be set to logical
max_replication_slots should be at least 10
For RDS, verify logical replication is enabled in your parameter group
On Cloud SQL, ensure logical decoding is enabled

If issues persist after checking these common points, reach out at hello@trysuperapi.com.

Supported Databases

On this page