¿Qué es el pooling de conexiones serverless?

El pooling de conexiones serverless es una técnica que comparte pocas conexiones reales de base de datos entre muchas instancias de función efímeras. Existe porque dos modelos de escalado discrepan: el cómputo serverless responde a la carga multiplicando instancias, mientras la base de datos trata cada conexión como un recurso caro, respaldado por memoria y con techo rígido. Junta los dos de forma ingenua y un pico de tráfico modesto se convierte en una caída con too many connections.

Puntos clave

La falla, observada desde la base de datos

-- Lo que la base ve durante un pico de tráfico serverless:
SELECT state, count(*)
FROM pg_stat_activity
GROUP BY state;
--  active               |   14
--  idle                 |  483     ← estacionadas por instancias calientes
SHOW max_connections;    --  100    ← el techo que ya reventaron

-- Cada conexión es un proceso real reteniendo memoria real —
-- por eso el techo existe, y por eso subirlo no es el arreglo.

La forma del problema: cada instancia de función abre su propia conexión, la retiene durante el ocio entre invocaciones, y la cantidad de instancias la decide el tráfico, no tú. La reutilización ocurre solo dentro de una instancia caliente — nunca entre instancias —, así que concurrencia 300 significa 300 pools de una conexión. Subir max_connections compra holgura a un costo real de memoria y pierde contra el siguiente pico más grande.

En un backend gestionado, el código de aplicación se sale de esta pelea por completo — las llamadas de SDK son solicitudes HTTPS sin estado, y ningún cliente retiene jamás una conexión de base de datos:

// JavaScript / Node.js — Back4app JS SDK
// Inside a serverless function: no driver, no pool, no connection to leak.
// Each SDK call is a stateless HTTPS request; pooling happens platform-side.
Parse.initialize('APP_ID', 'JS_KEY');
Parse.serverURL = 'https://parseapi.back4app.com';

export async function handler(event) {
  const query = new Parse.Query('Order');
  query.equalTo('status', 'pending');
  query.limit(20);
  const orders = await query.find();  // request returns; nothing stays open
  return orders.map((o) => o.id);
}
// 1,000 concurrent invocations = 1,000 HTTP requests,
// not 1,000 database connections.

// Flutter / Dart — Back4app Flutter SDK
// No driver, no pool, no connection to leak from the client side.
// Each SDK call is a stateless HTTPS request; pooling happens platform-side.
await Parse().initialize(
  'APP_ID',
  'https://parseapi.back4app.com',
  clientKey: 'CLIENT_KEY',
);

Future<List<String>> pendingOrderIds() async {
  final query = QueryBuilder<ParseObject>(ParseObject('Order'))
    ..whereEqualTo('status', 'pending')
    ..setLimit(20);
  final response = await query.query(); // request returns; nothing stays open
  return response.results!
      .map((o) => (o as ParseObject).objectId!)
      .toList();
}
// A burst of clients = a burst of HTTP requests,
// not a burst of database connections.

// iOS / Swift — Back4app Swift SDK
// No driver, no pool, no connection to leak from the client side.
// Each SDK call is a stateless HTTPS request; pooling happens platform-side.
ParseSwift.initialize(
  applicationId: "APP_ID",
  clientKey: "CLIENT_KEY",
  serverURL: URL(string: "https://parseapi.back4app.com")!
)

let query = Order.query("status" == "pending")
  .limit(20)
query.find { result in
  if case .success(let orders) = result {
    render(orders)                 // request returned; nothing stays open
  }
}
// A burst of clients = a burst of HTTP requests,
// not a burst of database connections.

// Android / Kotlin — Back4app Android SDK
// No driver, no pool, no connection to leak from the client side.
// Each SDK call is a stateless HTTPS request; pooling happens platform-side.
Parse.initialize(
    Parse.Configuration.Builder(context)
        .applicationId("APP_ID")
        .clientKey("CLIENT_KEY")
        .server("https://parseapi.back4app.com")
        .build()
)

val query = ParseQuery.getQuery<ParseObject>("Order")
query.whereEqualTo("status", "pending")
query.limit = 20
query.findInBackground { orders, e ->
    if (e == null) render(orders)  // request returned; nothing stays open
}
// A burst of clients = a burst of HTTP requests,
// not a burst of database connections.

Cómo el pooler absorbe el fan-out

Un pooler como PgBouncer acepta conexiones de cliente de a miles — cada una barata de su lado — y presta conexiones reales de servidor desde un pool pequeño solo cuando llega trabajo. La base ve veinte conexiones calmas; quinientas funciones creen tener una cada una. Cuando la demanda excede el pool, los clientes esperan milisegundos en una cola en vez de recibir errores — convirtiendo una falla dura en latencia modesta.

El dimensionamiento del pool es donde la intuición más falla. El paralelismo útil de una base está acotado por núcleos y disco — el rendimiento típicamente alcanza su pico con un pool de unas pocas decenas, cerca del número de núcleos por dos, y luego cae a medida que más conexiones suman contención. La aritmética del pooler funciona porque las solicitudes serverless son cortas: una conexión que atiende una transacción de 8 ms puede atender bastante más de cien por segundo, así que veinte conexiones reales absorben con comodidad miles de invocaciones de función. El pool no es un caché de conveniencia; es un cuello de botella deliberado, colocado donde encolar es barato.

La perilla crucial es cuánto dura el préstamo.

Transaction pooling vs. session pooling

El modo transacción es lo que vuelve viables las cargas serverless — una función que corre una transacción de 8 ms no debería ser dueña de una conexión durante su vida caliente de varios minutos —, pero no es gratis: todo lo que asume que “mi conexión” persiste entre sentencias se convierte en un bug sutil. El consejo consagrado: transaction pooling para el tráfico de solicitudes, y una conexión directa o por sesión para migraciones y cualquier cosa con estado.

Casos de uso comunes

• Funciones serverless y de edge golpeando SQL. El caso canónico — cantidades de instancias irregulares contra un presupuesto fijo de conexiones.
• Muchos servicios pequeños, una base. Veinte servicios × pools por defecto de diez conexiones = 200 conexiones que nadie planificó; un pooler compartido devuelve la cordura a la aritmética.
• Plataformas multi-tenant. Las cargas por tenant multiplican la demanda de conexiones; el pooling mantiene aplicable el presupuesto de la base compartida.
• Ráfagas de tráfico en bases modestas. Los picos del día de lanzamiento se encolan en el pooler por milisegundos en vez de dar error en la base.
• Proteger el primario durante incidentes. Un pool de tamaño fijo es un mamparo: los clientes desbocados agotan la cola del pooler, no la memoria de la base.

¿Deberías operar tu propio pooler? Matriz de decisión

La asimetría honesta: un pooler resuelve el agotamiento de conexiones; un backend gestionado lo disuelve. Cuando los clientes hablan HTTPS con APIs generadas automáticamente, el fan-out nunca llega a la capa de base de datos — el pooling sigue ocurriendo, pero como infraestructura bien probada de alguien más y no como componente tuyo.

Limitaciones y trade-offs

• Un pooler es un componente. Necesita despliegue, monitoreo, failover y upgrades — cambiaste un problema de recursos por un problema de operación, a un tipo de cambio favorable pero no nulo.
• El modo transacción cambia la semántica. Prepared statements, variables de sesión y advisory locks dejan de comportarse como documenta el manual; las fallas son intermitentes y dependientes de la carga — el peor tipo.
• Un salto extra cuesta latencia. Típicamente submilisegundo dentro de la red, pero está en el camino de cada consulta.
• El pooler puede ser el cuello de botella. Un pooler de un solo hilo bajo un pico violento encola profundo; el techo se movió, no desapareció.
• El pooling no arregla consultas lentas. Raciona conexiones; una consulta que retiene su préstamo por segundos mata de hambre al pool. Las consultas rápidas — y los índices detrás de ellas — siguen siendo la palanca real de capacidad.

Pooling de conexiones en Back4app

Back4app es una plataforma open-source de Backend as a Service (BaaS) que combina base de datos gestionada, APIs REST y GraphQL generadas automáticamente, autenticación, almacenamiento de archivos y funciones serverless con Cloud Code. Su arquitectura responde la pregunta del pooling de forma estructural: las apps cliente y las funciones de Cloud Code emiten solicitudes HTTPS sin estado, y la capa de servidor de la plataforma — no tu código — mantiene pools de conexiones longevos y bien dimensionados hacia la base gestionada. El fan-out de instancias del lado del cómputo nunca se traduce en fan-out de conexiones del lado de la base, que es exactamente la propiedad que este artículo entero existe para lograr.