Database Access Patterns

Database access patterns in serverless systems are mostly about matching the data store to the access pattern and preventing bursty function concurrency from overwhelming the store. The function model does not remove database design. It makes weak database choices visible faster because every cold start, retry, and scale event puts pressure on connection limits, hot partitions, and inefficient query shapes.

The first decision is not “which database is modern.” It is “what kind of read and write behavior does this function really need?” Relational stores are strong for transactions and joins. Key-value stores are strong for direct lookup by key. Document stores help when aggregates evolve flexibly. Analytical stores are for scans, aggregates, and reporting workloads that should not live on the request path.

    flowchart TD
	    A["Function invocation"] --> B{"Access pattern"}
	    B -->|transactional writes| C["Relational store"]
	    B -->|lookup by key| D["Key-value store"]
	    B -->|aggregate document| E["Document store"]
	    B -->|large scans or reporting| F["Analytical store"]
	    A --> G["Connection and concurrency limits"]
	    G --> C
	    G --> D
	    G --> E
	    G --> F

What to notice:

• store choice follows workload shape, not fashion
• connection and concurrency behavior still matter even when the database choice is correct
• analytical and transactional workloads should usually be separated

Match the Store to the Query

A serverless system often works best when different functions touch different persistence shapes:

• checkout and payment confirmation may need relational transactions
• session lookup or idempotency keys may fit a key-value store
• product catalog documents may work well in a document store
• dashboards and historical reporting usually belong in an analytical system or precomputed read model

The anti-pattern is forcing every access pattern through one database just because it already exists.

Connection Management Is a Real Constraint

Traditional application servers often hold a stable pool of database connections. Serverless functions do not behave that way. A sudden concurrency spike can create many short-lived execution environments, each trying to open its own connections. That is how teams accidentally take down a relational database with a perfectly ordinary traffic burst.

Typical mitigations include:

• reusing a client across warm invocations when the runtime allows it
• using a connection proxy or pooling layer for relational stores
• limiting function concurrency for fragile dependencies
• preferring key-value or HTTP-native managed stores for high-fan-out serverless paths

 1let dbClientPromise: Promise<DatabaseClient> | undefined;
 2
 3function getDbClient(): Promise<DatabaseClient> {
 4  if (!dbClientPromise) {
 5    dbClientPromise = createDatabaseClient({
 6      endpoint: process.env.DB_ENDPOINT!,
 7      connectionMode: "pooled",
 8    });
 9  }
10
11  return dbClientPromise;
12}
13
14export async function handler(orderId: string) {
15  const db = await getDbClient();
16  return db.queryOne("select * from orders where order_id = ?", [orderId]);
17}

What this demonstrates:

• client setup is moved outside the handler so warm environments can reuse it
• this reduces connection churn but does not eliminate the need for concurrency control
• the application still needs query discipline and dependency-aware scaling

Throughput Patterns Matter More Than Many Teams Expect

The right database can still struggle if each invocation performs too many small remote calls. Serverless systems benefit from:

• batching writes where correctness allows it
• avoiding N+1 query behavior across repeated function calls
• separating synchronous request-path reads from heavy reporting
• using append or event capture paths plus downstream projection when write spikes are high

This is especially important when the billing model punishes latency and the platform can scale faster than the database.

 1function_profiles:
 2  order-api:
 3    store: relational
 4    concurrency_limit: 50
 5  idempotency-check:
 6    store: key-value
 7    access_pattern: single-key lookup
 8  sales-dashboard-projector:
 9    store: analytical
10    trigger: hourly-batch

Common Mistakes

• connecting every function invocation directly to a fragile relational backend with no pooling strategy
• using a transactional database for large analytical scans on the request path
• assuming “managed database” means infinite burst tolerance
• choosing a store first and designing query patterns later

Design Review Question

An order API runs as functions behind an API gateway. Traffic spikes are short but intense. The team uses a relational database directly from each function and now sees connection exhaustion during promotions. What should be revisited first?

The stronger answer is access pattern and concurrency design, not just database size. The team likely needs connection pooling or proxying, lower request-path concurrency against that store, and possibly a split between transactional reads and high-volume derived reads. The issue is not that serverless and relational databases can never work together. The issue is treating bursty functions as if they were stable long-lived app servers.

Check Your Understanding