Як налаштувати 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 та PostgreSQL?

Вибір залежить від вашої моделі даних. Якщо вам потрібні складні агрегації, JOIN та транзакції — обирайте Neon (PostgreSQL). Якщо ви маєте справу з високими навантаженнями та простими запитами — DynamoDB з Single-Table Design забезпечить затримку в 5 разів нижчу, ніж MySQL при 1000+ запитів/с.

Чи підходить Serverless для вашого бізнесу?

Serverless архітектура ідеальна для проєктів з нерівномірним навантаженням, де важлива економія ресурсів. Наприклад, для SaaS-продукту з 10 000 користувачів вартість DynamoDB On-Demand складає близько $50/міс., що в 3 рази дешевше за виділений RDS.

Порівняння варіантів

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 (в 10 разів швидше).
• Час індексації нових даних скоротився втричі завдяки паралельним операціям.
• Команда отримала можливість створювати гілки для кожного 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 днів.

Терміни варіюються залежно від складності схеми та обсягу даних. Отримайте консультацію щодо вашого проєкту — зв'яжіться з нами для оцінки. Ми підберемо оптимальне рішення та запропонуємо план робіт.