Serverless Database Setup: DynamoDB, PlanetScale, and Neon

Imagine your e-commerce site on RDS starts slowing down during peaks, and you're overpaying for idle resources. Serverless databases solve this—they automatically scale to zero when idle and charge per consumption. But incorrect schema design can nullify savings: for example, frequent scans in DynamoDB can cost more than fixed infrastructure. We set up serverless databases for high-load projects: DynamoDB, PlanetScale, and Neon. With 5+ years of experience in serverless architectures, we have implemented solutions for 50+ projects—from e-commerce to IoT.

According to AWS documentation, proper Single-Table Design reduces read operations by up to 90%.

Why choose a serverless database?

Serverless databases eliminate the need for infrastructure management. You don't pay for idle resources, and scaling happens automatically. For projects with uneven load, this reduces infrastructure costs by 35–40%. However, incorrect schema design can negate all advantages: for example, frequent scans in DynamoDB will lead to high expenses.

Comparison of options

DynamoDB: Designing for Serverless

DynamoDB requires thinking about data access before schema design. A poorly designed table is expensive and slow. The only correct approach is Single-Table Design, where the entire domain is stored in one table, and PK/SK encode the entity type:

# Схема для e-commerce # PK | SK | Данные # USER#u123 | PROFILE | {name, email} # USER#u123 | ORDER#o456 | {status, total, items} # USER#u123 | ORDER#o789 | {status, total, items} # ORDER#o456 | ITEM#i001 | {product_id, qty, price} # PRODUCT#p001 | METADATA | {title, description} import boto3 from boto3.dynamodb.conditions import Key dynamodb = boto3.resource('dynamodb') table = dynamodb.Table('ecommerce') def get_user_with_orders(user_id: str) -> dict: response = table.query( KeyConditionExpression=Key('PK').eq(f'USER#{user_id}') & Key('SK').begins_with('ORDER#') ) return response['Items'] def put_order(user_id: str, order: dict): with table.batch_writer() as batch: batch.put_item(Item={ 'PK': f'USER#{user_id}', 'SK': f'ORDER#{order["id"]}', **order }) batch.put_item(Item={ 'PK': f'ORDER#{order["id"]}', 'SK': 'METADATA', 'GSI1PK': f'STATUS#{order["status"]}', 'GSI1SK': order['created_at'], **order }) 

Global Secondary Index (GSI) — for alternative access patterns, e.g., fetching all orders by status.

DynamoDB On-Demand vs Provisioned

On-Demand: pay per read/write. No capacity planning. Ideal for unpredictable traffic or new applications.

Provisioned + Auto Scaling: set a baseline RCU/WCU, auto-scales during peaks. Cheaper under predictable load.

resource "aws_dynamodb_table" "ecommerce" { name = "ecommerce" billing_mode = "PAY_PER_REQUEST" # On-demand hash_key = "PK" range_key = "SK" attribute { name = "PK" type = "S" } attribute { name = "SK" type = "S" } attribute { name = "GSI1PK" type = "S" } attribute { name = "GSI1SK" type = "S" } global_secondary_index { name = "GSI1" hash_key = "GSI1PK" range_key = "GSI1SK" projection_type = "ALL" } ttl { attribute_name = "expires_at" enabled = true } } 

Neon: Serverless PostgreSQL

Neon separates compute and storage. Compute scales to zero when inactive, storage is billed by volume. Built-in branching allows creating isolated environments in seconds.

import psycopg2 import os conn = psycopg2.connect(os.environ['DATABASE_URL']) with conn.cursor() as cur: cur.execute("SELECT * FROM orders WHERE user_id = %s", (user_id,)) orders = cur.fetchall() 

Branching in Neon:

neon branches create --name feature/new-schema --parent main neon connection-string feature/new-schema # → postgresql://user:[email protected]/neondb 

PlanetScale

MySQL-compatible service with branching workflow, no foreign key constraints (vitess-based). Uses HTTP protocol, especially good for Lambda:

import { connect } from '@planetscale/database' const conn = connect({ host: process.env.DATABASE_HOST, username: process.env.DATABASE_USERNAME, password: process.env.DATABASE_PASSWORD }) const results = await conn.execute( 'SELECT * FROM orders WHERE user_id = ?', [userId] ) 

How to set up connection pooling for Lambda: step-by-step guide

1. Determine the DB type: for RDS use RDS Proxy, for Neon use built-in pooler, for PlanetScale the HTTP protocol already solves the problem.
2. For PostgreSQL with PgBouncer: deploy PgBouncer near Lambda (e.g., in VPC), set pool_mode = transaction.
3. When using Prisma: replace direct connections with Prisma Accelerate via environment variable DATABASE_URL.
4. Check the number of concurrent connections: for 100 Lambda functions, about 20 connections in the pool will be needed.
5. Test cold start: the first request after idle should not exceed 300 ms.

Connection pooling for Lambda

Lambda creates a new connection on each cold start. With 100 concurrent Lambdas—100 connections. This kills PostgreSQL/MySQL. Solutions:

Case study: Migrating a client from RDS to Neon

Project: e-commerce store with seasonal peaks (Black Friday). Database: PostgreSQL 13 on RDS. Average load: 2000 requests/s, peak: 15,000. RDS couldn't handle it, requiring overprovisioned capacity.

Solution: Migration to Neon with PostgreSQL 15. Results:

• Infrastructure cost reduced by 35% (from 450,000 ₽ to 290,000 ₽ per month).
• Cold start (after idle) — 200 ms vs previous 2 s on RDS.
• Indexing new data time reduced threefold thanks to parallel operations.
• The team gained the ability to create branches for each PR, accelerating development.

What's included in the work

• Schema design (Single-Table Design for DynamoDB, normalization for Neon/PlanetScale).
• Connection pooling setup (RDS Proxy, PgBouncer, built-in).
• Query optimization (indexes, GSIs, benchmarks).
• CI/CD for branching (automatic branch creation on pull requests).
• Schema documentation and team instructions.
• Developer training (your engineers can make changes independently).
• 30-day support guarantee after delivery.

Estimated timelines

• DynamoDB single-table design + basic operations — 3-5 days.
• Neon / PlanetScale setup + pooling — 1-2 days.
• Migration of an existing database to serverless — 5-14 days.

Timelines vary depending on schema complexity and data volume. Get a consultation for your project—contact us for an assessment. We'll select the optimal solution and propose a work plan.