Neon

Коротко: Провайдер «безсерверного Postgres» — справжня база даних PostgreSQL, але без керування власним сервером, з рядком підключення замість ручного встановлення.

Докладніше: У панелі ви отримуєте рядок підключення («Connection Details»), який можна будь-коли переглянути відкритим текстом (на відміну, наприклад, від ключа API, що показується один раз). Технічно він виконує цілком звичайний SQL, сумісний зі стандартними інструментами на кшталт pg_dump/psql.

Подробиці

Розділення сховища й обчислень

Neon технічно розділяє сховище й обчислення: самі дані живуть на розподіленому шарі зберігання (всередині — спеціально побудована система на основі журнально-структурованого зберігання, а не класичного розкладу файлової системи Postgres), тоді як «обчислювальний» екземпляр — власне процес PostgreSQL, що відповідає на запити, — можна запускати й вимикати за потреби без втрати даних. Саме це уможливлює Neon Auto-Suspend, і це принципова відмінність від класичного хостингу «орендуй цілий сервер, що працює цілодобово» (наприклад, класичний екземпляр RDS в AWS чи самостійно керований сервер Postgres). Ця архітектура — частина ширшої тенденції в хостингу баз даних останніх років — «безсерверний Postgres» — до якої, крім Neon, належать і такі провайдери, як Supabase (додатково об’єднує навколо Postgres функції автентифікації, сховища та реального часу) чи AWS Aurora Serverless, хоча глибина розділення сховища й обчислень різниться.

Розгалуження

Функція, якої в такому вигляді немає в класичному встановленні Postgres: розгалуження (branching). Ви можете будь-коли створити повну копію («гілку») бойової бази даних, яка спочатку практично не потребує додаткового сховища (copy-on-write — нові блоки пишуться лише тоді, коли дані в гілці справді змінюються). Це корисно, наприклад, щоб спершу перевірити ризиковану міграцію на копії, перш ніж виконувати її на справжній бойовій базі даних, або щоб автоматично створювати окрему ізольовану копію бази даних для кожного попереднього розгортання pull request (поширений шаблон CI/CD: одна гілка на PR, видаляється автоматично після злиття/закриття PR). Гілки можна створювати як через панель, так і через Neon CLI/API, що добре інтегрується в автоматизовані конвеєри розгортання.

Рядок підключення та пулінг

Рядок підключення зазвичай має вигляд:

postgresql://<user>:<password>@<endpoint>.neon.tech/<database>?sslmode=require

sslmode=require у Neon обов’язковий — незашифровані з’єднання відхиляються на боці сервера, що може призвести до загадкового повідомлення про помилку, якщо ви випадково перевірите з’єднання локально без цього прапорця. Для з’єднань із безсерверних середовищ (наприклад, Vercel Functions, що потенційно відкривають нові з’єднання на кожен запит) Neon додатково пропонує рядок «pooled connection» через PgBouncer (окремий пулер з’єднань між застосунком і власне екземпляром Postgres) у режимі «transaction pooling». Це важливо, оскільки сам Postgres допускає лише обмежену кількість одночасних з’єднань (зазвичай порядку сотень для невеликих розмірів обчислень) — за безлічі коротких викликів безсерверних функцій, кожна з яких відкриває своє з’єднання, цей ліміт інакше швидко вичерпувався б («вичерпання з’єднань»). Недолік рядка з пулінгом: деякі функції Postgres, що потребують довгоживучого сеансу (наприклад, LISTEN/NOTIFY, підготовлені оператори через межі сеансів чи дорадчі блокування), у режимі transaction pooling працюють ненадійно — для них потрібне пряме з’єднання без пулінгу.

У порівнянні з альтернативами

Порівняно з Supabase (значно ширшим, включно з власною системою автентифікації та сховищами) Neon навмисно зроблений компактним — чиста база даних Postgres з безсерверними властивостями, без додаткових функцій платформи. Порівняно з PlanetScale (заснованим на MySQL-сумісному Vitess, а не на справжньому Postgres) Neon зберігає повну сумісність з екосистемою Postgres — будь-який інструмент, що працює зі «справжнім» Postgres (включно з pg_dump/psql, див. pg_dump і psql), працює без змін.

Див. також: pg_dump і psql, Drizzle ORM