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.

Why Serverless Development? The Real Economics and Technical Trade-offs

Serverless does not mean "without servers". Servers exist—you just don't manage them. It's more accurate to think of it as "without server management": no OS patching, no nginx configuration, no disk space monitoring. The function receives an event, processes it, and returns a response. The provider decides where to run it. Мы занимаемся serverless-архитектурой более 5 лет и реализовали 30+ проектов на AWS Lambda, Vercel Functions и Cloudflare Workers. Гарантируем, что ваша система масштабируется без переплат — при условии правильного выбора платформы и оптимизации холодного старта.

Cold start — Lambda's main pain point on Node.js. In VPC, cold start reached 10 seconds before recent improvements. For production functions with latency requirements: Provisioned Concurrency (keeps instances warm), SnapStart for Java, minimize bundle via tree-shaking. Our typical optimization reduces cold start from 3.2s to 400ms.

Practical case: an image processing function (resize, WebP conversion, upload to S3). Bundle with sharp was 40MB due to native binaries. Solution: Lambda Layer with sharp, main function 800KB. Cold start dropped from 3.2s to 400ms. Lambda Layers — shared dependencies between functions. Up to 5 layers per function, each up to 250MB. Standard practice: layer with heavy dependencies (sharp, puppeteer, ffmpeg), layer with common business logic. Infrastructure for Lambda via AWS CDK or Terraform. SAM — for beginners, CDK — for serious projects with type safety.

Edge Runtime is fundamentally different: the function runs on a V8 isolate in the nearest Vercel CDN point (120+ regions). No cold start as such — the isolate starts in ~0ms. But strict limitations: no Node.js API (fs, crypto via Web API), no database access via TCP (only via HTTP API), bundle size up to 4MB. Edge Runtime is ideal for: middleware (auth check, redirect, A/B test), response transformations, geolocation logic, Edge Config. Not suitable for: accessing PostgreSQL, heavy computations, file system operations.

Cloudflare Workers run on V8 isolates in 300+ points of presence. Latency for the user is literally the nearest data center. Cold start < 1ms. Workers Durable Objects solve the state problem at the edge: each Durable Object is a single coordination point, running in one region. Ideal for: game rooms, real-time documents, rate limiting without races. Workers KV — eventually consistent storage. Writes propagate to all regions in ~60 seconds. Not suitable for financial transactions, suitable for configs, feature flags, cache. D1 — SQLite on the edge. Works great on a single read replica, write latency depends on distance to primary region. Not ideal for global write-heavy applications.

Ecosystem: Hono.js — a minimalist router that works on Workers, Deno, Bun, Node.js. Good choice if you need unified code for edge and server.

Vendor lock-in — a real problem. Lambda-specific code (handler signature, Lambda context) is hard to port. Hono.js, Remix, or adapters like @hono/node-server help keep logic portable. Мы проектируем абстракции, позволяющие сменить провайдера с минимальными изменениями.

How We Optimize Cold Start in AWS Lambda?

Cold start is Lambda's worst enemy. Here’s a step‑by‑step optimisation checklist we apply:

1. Minimise bundle size — tree‑shake dependencies, use Lambda Layers for native binaries (sharp, puppeteer). Target < 1MB.
2. Enable Provisioned Concurrency for latency‑critical functions — costs extra but cuts cold start to near zero.
3. Use SnapStart for Java (Lambda) — reduces init time by 90%+.
4. Avoid VPC unless necessary — if you need VPC, use AWS PrivateLink or Elastic Network Interface optimisation.
5. Warm‑up strategies — scheduler pinging function every 5 minutes (but only for low‑volume functions, otherwise Provisioned Concurrency cheaper).

Result: our clients typically see cold start drop from 2–4s to under 500ms. For a fintech API handling 50k requests/day, that means 3 fewer seconds of latency per request during peak scale.

When Does Serverless Not Fit? Cost Comparison

Serverless saves money when traffic is unpredictable or sparse — up to 70% reduction compared to dedicated servers. But it becomes expensive under constant high load. Example: a function processing 1 million requests/day at 300ms each costs about $100–200/month on Lambda. Equivalent EC2 instance might cost $50/month. For such steady workloads, Fargate or EC2 is cheaper.

Long computations (>15 min on Lambda, >30s on Vercel) require Fargate or a regular server. WebSocket server with state — no persistent process. Tasks with frequent disk access — ephemeral storage, /tmp on Lambda 512MB–10GB.

What’s Included in Serverless Development Service?

Мы предлагаем serverless-разработку под ключ. В каждый проект входит:

• Архитектурная документация (схема event‑driven потоков, выбор платформы, justification).
• Реализация функций с unit‑ и integration‑тестами.
• CI/CD pipeline (GitHub Actions / GitLab CI) с preview‑деплоями.
• Infrastructure as Code (Terraform / AWS CDK / Pulumi).
• Мониторинг и observability (OpenTelemetry, structured logging, distributed tracing).
• 30‑дневная пост‑релизная поддержка и оптимизация производительности.

Typical Mistakes in Serverless Development and How We Avoid Them

• Ignoring cold start — we measure and budget for it from day one.
• Over‑engineering state — many teams try to use Workers Durable Objects for simple caching; KV is often enough.
• No distributed tracing — without trace IDs across SQS › Lambda › DynamoDB streams, debugging is blind. We integrate AWS X‑Ray or OpenTelemetry automatically.
• Underestimating cost at scale — we simulate load patterns and compare serverless vs. container costs before committing.

Закажите serverless архитектуру под ключ — свяжитесь с нами для бесплатной оценки вашего проекта. Сроки: от 2 недель для MVP, до 10 недель для миграции монолита. Стоимость рассчитывается индивидуально, ориентировочно от $2,000 до $15,000 в зависимости от сложности.