Настройка Serverless-баз данных: DynamoDB, PlanetScale и Neon под ключ

Представьте: ваш интернет-магазин на RDS начинает тормозить в пики, а вы переплачиваете за простаивающие ресурсы. Serverless базы данных решают эту проблему — они автоматически масштабируются до нуля при простое и тарифицируются по потреблению. Но неправильное проектирование схемы сведёт экономию на нет: например, частые сканирования в DynamoDB могут обойтись дороже фиксированной инфраструктуры. Мы настраиваем serverless БД для высоконагруженных проектов: DynamoDB, PlanetScale и Neon. С 5+ годами опыта в serverless архитектурах мы внедрили решения для 50+ проектов — от e-commerce до IoT.

Согласно документации AWS, корректное применение Single-Table Design снижает количество операций чтения до 90%.

Почему стоит выбрать serverless базу данных?

Serverless БД устраняют необходимость управления инфраструктурой. Вы не платите за простаивающие ресурсы, а масштабирование происходит автоматически. Для проектов с неравномерной нагрузкой это снижает стоимость инфраструктуры на 35–40%. Однако неправильное проектирование схемы может свести на нет все преимущества: например, частые сканирования в DynamoDB приведут к высоким расходам.

Сравнение вариантов

DynamoDB: проектирование под serverless

DynamoDB требует думать о доступе к данным до проектирования схемы. Плохо спроектированная таблица — дорогая и медленная. Единственный правильный подход — Single-Table Design, когда весь домен хранится в одной таблице, а PK/SK кодируют тип сущности:

# Схема для 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) — для альтернативных паттернов доступа, например, получить все заказы по статусу.

DynamoDB On-Demand vs Provisioned

On-Demand: платишь за каждый read/write. Нет планирования мощности. Идеально для unpredictable трафика или новых приложений.

Provisioned + Auto Scaling: задаёшь baseline RCU/WCU, автомасштабирование при пиках. Дешевле при предсказуемой нагрузке.

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 разделяет compute и storage. Compute масштабируется до нуля при отсутствии активности, storage оплачивается по объёму. Встроенный branching позволяет создавать изолированные окружения за секунды.

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 в Neon:

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

PlanetScale

MySQL-совместимый сервис с branching workflow, без foreign key constraints (vitess-based). Использует HTTP-протокол, что особенно хорошо для 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]
)

Как настроить connection pooling для Lambda: пошаговое руководство

1. Определите тип БД: для RDS используйте RDS Proxy, для Neon — встроенный pooler, для PlanetScale — HTTP-протокол уже решает проблему.
2. Для PostgreSQL с PgBouncer: разверните PgBouncer рядом с Lambda (например, в VPC), настройте pool_mode = transaction.
3. При использовании Prisma: замените прямые подключения на Prisma Accelerate через переменную окружения DATABASE_URL.
4. Проверьте количество одновременных соединений: для 100 Lambda-функций потребуется около 20 соединений в пуле.
5. Протестируйте cold start: первый запрос после простоя не должен превышать 300 мс.

Connection pooling для Lambda

Lambda создаёт новое соединение при каждом cold start. При 100 concurrent Lambda — 100 соединений. Это убивает PostgreSQL/MySQL. Решения:

Кейс: миграция заказчика с RDS на Neon

Проект: интернет-магазин с сезонными пиками (Черная пятница). База данных — PostgreSQL 13 на RDS. Средняя нагрузка — 2000 запросов/с, в пике — 15 000. RDS не справлялся, приходилось держать избыточные мощности.

Решение: миграция на Neon с PostgreSQL 15. Итоги:

• Стоимость инфраструктуры снизилась на 35% (с $4.5k–2.9k/мес).
• Cold start (после перерыва) — 200 мс против прежних 2 с на RDS.
• Время индексации новых данных сократилось втрое благодаря параллельным операциям.
• Команда получила возможность создавать ветки для каждого PR, что ускорило разработку.

Что входит в работу

• Проектирование схемы (Single-Table Design для DynamoDB, нормализация для Neon/PlanetScale).
• Настройка connection pooling (RDS Proxy, PgBouncer, встроенный).
• Оптимизация запросов (индексы, GSIs, бенчмарки).
• CI/CD для branching (автоматическое создание веток при пулл-реквестах).
• Документация схемы и инструкции для команды.
• Обучение разработчиков (ваши инженеры смогут самостоятельно вносить изменения).
• Гарантия поддержки в течение 30 дней после сдачи.

Ориентировочные сроки

• DynamoDB single-table design + базовые операции — 3-5 дней.
• Neon / PlanetScale подключение + pooling — 1-2 дня.
• Миграция существующей БД на serverless — 5-14 дней.

Сроки варьируются в зависимости от сложности схемы и объёма данных. Получите консультацию по вашему проекту — свяжитесь с нами для оценки. Мы подберём оптимальное решение и предложим план работ.