Why would multiple services share the same database?

Sharing a database provides a single source of truth (eliminating sync complexity), cost efficiency (shared infrastructure), and transaction support across entities. Common examples include an API server, background worker, and cron job all accessing the same PostgreSQL instance.

What are PostgreSQL connection limits on Render?

Connection limits depend on instance memory. Instances with less than 8GB RAM support 100 connections; 8GB to 16GB support 200 connections. Each service's connection pool consumes part of this shared limit, so you must coordinate pool sizes across all services. See the connection limits documentation for details.

Should I use private or external database URLs?

Use private networking for service-to-database communication. Traffic stays off the public internet, reducing attack surface and latency. Retrieve the internal connection URL from your Render dashboard (DATABASEURLPRIVATE) instead of the external URL.

How do I size connection pools across multiple services?

Total pools must stay below your database limit minus reserved connections (approximately 3). For a 100-connection database, you might allocate 40 to your API, 30 to workers, 15 to cron jobs, and keep 12 as buffer. Monitor pool exhaustion and adjust based on actual concurrent query load.

When should I add a read replica?

Add a read replica when your read-to-write ratio exceeds 3:1, read queries consume over 75% of database capacity, or you need high availability for read operations. Render manages replication setup automatically.

How do I handle replication lag with read replicas?

Read replicas replicate asynchronously, so recent writes may not appear immediately. Read from the primary immediately after writes when consistency matters, implement application-level caching, or design your UX to tolerate eventual consistency.

How do I diagnose connection exhaustion?

Query pgstatactivity to identify which services hold connections and their state (active vs idle). Group by application_name to see connection counts per service. Idle connections may indicate leaked connections that aren't being returned to the pool.

How do I handle database migrations when services deploy independently?

Your schema must support both old and new code versions simultaneously. Add new columns as nullable, never drop columns while any service references them, and use the Expand/Contract pattern: deploy new schema, update all services, then remove deprecated elements.

Databases

Connecting Multiple Services to a Shared Database

November 19, 2025

Multi-service database access patterns

Modern application architectures frequently require multiple services to access shared data resources. For example, a REST API, a background worker, and a scheduled cron job might all query the same PostgreSQL instance. Render simplifies this topology by providing fully managed databases with built-in private networking, allowing your services to connect securely without configuring VPCs, firewalls, or complex peering rules.

However, sharing a database still introduces resource allocation challenges: database connection limits become shared constraints, network topology affects security and performance, and connection pooling requires coordination across service boundaries. This guide shows you how to navigate these patterns using Render's platform features.

Prerequisites for implementing these patterns:

Active Render account with services deployed
PostgreSQL database provisioned on Render
Understanding of environment variable configuration in your runtime
Familiarity with your framework's database client library (examples use Node.js pg, but concepts apply to Python, Go, etc.)

Understanding shared database architecture

Shared database architecture defines a pattern where multiple independent services maintain connections to a single database instance. Service A (API server), Service B (worker process), and Service C (scheduled job runner) all connect to Database D simultaneously.

Why you might share databases:

Data consistency: A single source of truth eliminates synchronization complexity
Cost efficiency: Database resources serve multiple workloads from shared infrastructure
Transaction support: Cross-entity transactions remain possible when data resides in one database

Connection limits as shared resource constraint: PostgreSQL databases on Render have maximum connection limits that depend on the instance's total memory (RAM). Learn more in the PostgreSQL connection limits documentation. For instances with less than 8GB of RAM, the limit is 100 connections. For instances with 8GB to less than 16GB, it's 200 connections. Each service consumes a subset of this limit. If Service A configures a pool of 20 connections, Service B uses 15, and Service C uses 10, you've allocated 45 of your available connections before handling any queries.

Private networking for service-to-database communication

Render's private networking enables services within the same region to communicate using internal hostnames that resolve to private IP addresses. Unlike traditional cloud providers that require manual VPC configuration and security group management, Render automatically isolates your services in a private network. Traffic between a service and database using private networking never traverses the public internet.

Security benefits:

Reduced attack surface: Database ports aren't exposed to internet scanning when using internal URLs
Network isolation: Only services within your Render account's private network in the same region can resolve internal hostnames

Performance implications:

Lower latency: Internal network routing minimizes query latency by enabling communication over your private network

Connection pattern: You'll retrieve the internal connection URL from Render's dashboard (format: postgresql://USER:PASSWORD@INTERNAL_HOST:PORT/DATABASE) and use it in place of the external URL.

javascript

const { Pool } = require("pg");

const pool = new Pool({
  connectionString: process.env.DATABASE_URL_PRIVATE,
  max: 20, // Limit this service to 20 connections to avoid starving others
  idleTimeoutMillis: 30000, // Close idle connections to free up resources
  connectionTimeoutMillis: 2000, // Fail fast if pool is exhausted
});

module.exports = pool;

Connection pooling across multiple services

Establishing a new encrypted connection for every database query introduces significant latency (SSL handshake, authentication). Connection pooling solves this by maintaining a cache of reusable connections.

A pool maintains N open connections (the "pool size"). When your application needs to query the database:

It borrows an idle connection from the pool.
It executes the query.
It returns the connection to the pool for the next request.

See the node-postgres pooling documentation for implementation details.

Resource allocation formula: Total Service Pools ≤ Database Connection Limit - Reserved Connections (approx. 3).

Example calculation for a Render PostgreSQL instance with 100 connection limit (instances with less than 8GB RAM):

Reserved connections (superuser/monitoring): 3 connections
Usable connections: 97 connections
Service A (API): 40 connections
Service B (worker): 30 connections
Service C (scheduled jobs): 15 connections
Buffer: 12 connections

Pool sizing methodology:

Measure concurrent query load per service
Account for connection lifecycle and acquisition latency
Consider query duration impact on connection availability
Test under load and monitor pool exhaustion metrics

Monitoring connection utilization: Track active connections, idle connections, waiting requests, and connection errors per service. Configure alerts when waiting requests exceed zero consistently.

Read replicas for read-heavy workloads

Read replicas are separate database instances that maintain copies of a primary database through streaming replication. The primary handles writes; replicas handle reads. Render manages the complex replication setup automatically—you can provision a read replica directly from the dashboard without configuring replication slots, WAL levels, or follower recovery.

When to use read replicas:

Read-to-write ratio exceeds 3:1
Read query volume exceeds single database instance capacity
Different services have distinct read versus write patterns

javascript

const { Pool } = require("pg");

// Pool for write operations (Primary DB)
const primaryPool = new Pool({
  connectionString: process.env.DATABASE_URL_PRIMARY_PRIVATE,
  max: 10, // Keep write connections minimal
});

// Pool for read operations (Read Replica)
const replicaPool = new Pool({
  connectionString: process.env.DATABASE_URL_REPLICA_PRIVATE,
  max: 30, // Allocate more connections for read-heavy traffic
});

async function writeUser(userData) {
  // Writes always go to primary
  return primaryPool.query("INSERT INTO users (name, email) VALUES ($1, $2)", [
    userData.name,
    userData.email,
  ]);
}

async function readUser(userId) {
  // Reads can go to replica (tolerating eventual consistency)
  return replicaPool.query("SELECT * FROM users WHERE id = $1", [userId]);
}

module.exports = { writeUser, readUser };

Replication lag considerations: Read replicas replicate asynchronously, which can introduce some lag. You can handle this by reading from primary immediately after writes, implementing application-level caching, or designing UX to tolerate eventual consistency.

Security and operational patterns

Network security: Use private networking exclusively for service-to-database communication. Each service should use distinct database credentials with minimum required privileges.

sql

-- Read-only user for analytics service
CREATE USER analytics_service WITH PASSWORD 'strong_password';
GRANT CONNECT ON DATABASE production TO analytics_service;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO analytics_service;

Connection exhaustion diagnosis: Query pg_stat_activity to identify which services hold connections:

sql

SELECT
  application_name, -- Identify which service is holding connections
  state,            -- 'active' vs 'idle' helps find leaked connections
  COUNT(*) as connection_count
FROM pg_stat_activity
WHERE datname = 'your_database'
GROUP BY application_name, state;

Schema migration coordination: Services deploy independently, meaning your database schema must simultaneously support both the old and new versions of your application code during updates.

Backward compatibility: Add new columns as nullable; do not enforce NOT NULL constraints until all services have been updated to populate the column.
Destructive changes: Never drop columns or rename tables while any service version still references them. Use a multi-stage deploy process (Expand/Contract pattern) to deprecate old schema elements safely.

Architectural decision framework

Use shared database with private networking when:

Your services require transactional consistency across shared data
Connection volume remains within database capacity (< 80% of limit)
Services are maintained by the same team

Add read replicas when:

Read query volume exceeds 75% of database capacity
Read-to-write ratio exceeds 3:1
Services need high availability or reliability features for read operations

Consider separate databases when:

Your services have independent data with no shared entities
Connection exhaustion occurs despite optimization
Services are maintained by independent teams

Next steps

Ready to implement this architecture? Create a managed PostgreSQL database on Render to get private networking, automated backups, and one-click read replicas out of the box.