Настройка 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% (с 450 000 до 290 000 ₽/мес).
• 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 дней.

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