Мы анонсируем DBArena, сайт, на котором публикуются результаты тестирования производительности хостинговых провайдеров Postgres. Первые результаты сравнивают Supabase Postgres (с хранилищем по умолчанию), Supabase Postgres (с OrioleDB), Amazon RDS и Google Cloud SQL на семи размерах вычислительных ресурсов по пропускной способности, соотношению цены и производительности, а также задержке.

Supabase спонсирует DBArena. Методология является общедоступной, а все инструменты для запуска тестов имеют открытый исходный код. Каждоий результат включает в себя файл с сырыми данными, содержащий точные команды, конфигурацию и записанные метаданные, поэтому вы можете перезапустить любой тест и сравнить свои результаты с опубликованными.

Большинство опубликованных тестов баз данных исходят от вендоров, и их трудно сравнивать друг с другом. В них используются разные размеры инстансов, настроенные конфигурации с одной стороны и настройки по умолчанию с другой, а сами тесты сложно воспроизвести. Во многих отчетах метрики производительности приводятся без учета цены, что скрывает компромиссы, которые важны для команд.

На DBArena каждый провайдер запускает одинаковую рабочую нагрузку при одинаковом количестве vCPU и конфигурации ввода-вывода, а результаты нормализуются по стоимости. Настройки остаются дефолтными для каждого провайдера.

Первый релиз охватывает четыре продукта:

Supabase Postgres с кучным хранилищем по умолчанию
Supabase Postgres с OrioleDB (бета-версия)
Amazon RDS для PostgreSQL
Google Cloud SQL для PostgreSQL (редакция Enterprise)

Каждый продукт тестируется на семи уровнях вычислений: от Small (2 vCPU, 2 ГБ) до 8XLarge (32 vCPU, 128 ГБ). Продукты сопоставляются по количеству vCPU, и во всех тестах используется Postgres 17 с конфигурацией провайдера по умолчанию. Клиенты подключаются напрямую по TLS, без пулера соединений.

Каждый уровень тестируется в двух сценариях:

Попадание в кэш: набор данных помещается в память, коэффициент попадания в буферный кэш составляет не менее 99%.
Превышение кэша: набор данных в четыре раза больше доступной оперативной памяти, что принудительно вызывает чтение с диска. IOPS и пропускная способность диска согласованы между провайдерами.

Для каждой тестовой точки DBArena сообщает три метрики:

tpm: среднее количество транзакций в минуту за 60-минутный тестовый прогон.
tpm/$: количество транзакций в минуту на доллар ежемесячной стоимости по публичным базовым прейскурантным ценам без скидок.
p95 latency: задержка, в пределах которой завершаются 19 из 20 транзакций.

Рабочая нагрузка получена из TPC-C — стандартного теста, который моделирует систему обработки заказов. Время раздумий (think time) отключено, поэтому тест измеряет максимальную пропускную способность, которую может выдержать каждая база данных.

Эта рабочая нагрузка получена из бенчмарка TPC-C и не сопоставима с опубликованными результатами бенчмарка TPC-C, поскольку эта реализация не соответствует всем требованиям бенчмарка TPC-C.

Для каждого теста DBArena подготавливает свежую базу данных и генератор нагрузки в одном регионе. Тест запускает 30-минутный прогрев, который отбрасывается, за которым следует 60-минутное измерение. Он варьирует количество клиентов от одного до шести раз (на двух самых больших уровнях — до восьми раз) от количества vCPU, чтобы найти пиковую пропускную способность каждой базы данных. Каждый тест повторяется в свежей среде до тех пор, пока не будет получено три успешных прогона, а опубликованным результатом является медианный прогон при пиковой параллельности.

Первый раунд результатов измерялся в период с 25 сентября по 1 октября 2026 года. Он охватывает 62 опубликованных результата, полученных из более чем 750 отдельных тестовых прогонов. Эти результаты были опубликованы 2 октября, когда мы запустили DBArena на Supabase Select.

Каждый опубликованный результат имеет файл result.json в dbarena.com repository в разделе results/. В нем записывается подготовленная конфигурация инстанса, цена, версии программного обеспечения и точная команда, использованная для запуска теста.

Тесты запускаются с помощью трех инструментов с открытым исходным кодом:

dbarenactl планирует тестовые прогоны и отслеживает их прогресс.
benchctl подготавливает окружение и запускает рабочую нагрузку.
go-tpc — это генератор нагрузки, форк Supabase, в котором исправлен ряд проблем вышестоящего проекта.

Чтобы повторно запустить одну тестовую точку против Amazon RDS, например, настройте dbarenactl и benchctl с учетной записью AWS и выполните:

_10

dbarenactl run --candidate candidates/aws/rds/tpcc/manifest.yaml \

_10

--test-point xlarge/cache-exceeding \

_10

--iterations 3

Добавьте --dry-run к первой команде, чтобы предварительно просмотреть то, что будет развернуто, ничего не создавая.

Команда выводит идентификатор прогона (sweep ID). Когда прогоны завершатся, получите данные о ценах и экспортируйте результаты:

_10

dbarenactl pricing fetch --candidate candidates/aws/rds/tpcc/manifest.yaml

_10

dbarenactl results $SWEEP_ID

Одна рабочая нагрузка: все результаты получены из единой рабочей нагрузки, производной от TPC-C.
Без времени раздумий: поскольку время раздумий отключено, результаты показывают максимальную пропускную способность, а не поведение типичного приложения с периодами простоя.
Один регион на облако: тесты выполняются в AWS us-east-1 и GCP us-east1. Они не охватывают другие регионы, задержки между регионами или реплики.
Прейскурантные цены: расходы рассчитываются по публичным базовым ценам по запросу без скидок.
Сопоставление по vCPU. Продукты сопоставляются по количеству vCPU, а не по памяти, поэтому провайдеры с большим объемом ОЗУ на один vCPU имеют преимущество при некоторых размерах.
Размещение генератора нагрузки. Для Amazon RDS и Google Cloud SQL генератор нагрузки запускается в той же зоне доступности, что и база данных. Supabase не поддерживает выбор зоны доступности, поэтому на Supabase он запускается только в том же регионе.

Страница методологии подробно объясняет каждый из этих выборов.

Чтобы получать электронное письмо при публикации новых тестов, подпишитесь на рассылку DBArena.