SQLx против Diesel против SeaORM для быстрого бэкэнда Rust

SQLx, Diesel и SeaORM — это не три варианта одного и того же инструмента. SQLx — это низкоуровневый набор инструментов — драйвер Postgres, дополненный дополнительной проверкой. Diesel — это классический ORM в смысле Rust: слой типов над SQL. SeaORM — это ORM в смысле Ruby/Python: сущности, отношения, загрузка объектов. В таблице ниже представлены поддающиеся проверке факты, датированные 23 августа 2026 года.

Версии, загрузки и звезды: API crates.io и API GitHub, запрос сделан 23 августа 2026 г. Репозиторий SQLx отслеживается под transact-rs/sqlx (ранее launchbadge/sqlx).

Загрузки за последние 90 дней, в миллионах (полеrecent_downloads API crates.io). Источник: crates.io, интервью 23 августа 2026 г.

SQLx описывает себя как «асинхронный крейт на чистом Rust SQL с запросами, проверяемыми во время компиляции, без DSL» (официальный README, github.com/transact-rs/sqlx, по состоянию на 23 августа 2026 г.). Никакого построителя запросов, никаких сущностей: вы пишете SQL, а SQLx предлагает два способа его выполнения.

// Режим 1 — макрос времени компиляции: проверяется по реальной базе данных разработчиков.
let user = sqlx::query_as!(User, "SELECT id, email FROM users WHERE id = $1", user_id)
    .fetch_one(&pool)
    .await?;

// Режим 2 — динамический: таблица/столбцы определяются во время выполнения.
let sql = format!("SELECT * FROM {table} WHERE id = $1");
let row = sqlx::query(&sql).bind(user_id).fetch_one(&pool).await?;

Режим 1 требует наличия базы данных, доступной в момент cargo build — макрос подключается к ней для проверки типов. Режим 2 не имеет статических проверок, но принимает любую строку SQL, созданную во время выполнения, включая имена таблиц. Это режим, который использует Aurabase (раздел 06).

Распространенное возражение против режима 1: как встроить CI без доступной базы разработчиков? sqlx-cli отвечает в автономном режиме (официальный документ sqlx-cli, просмотрен 23 августа 2026 г.):

1. Локально, с подключенной базой данных разработчиков, запустите cargo sqlx prepare: метаданные каждого проверенного запроса записываются в папку .sqlx.
2. Зафиксируйте эту папку .sqlx в репозитории рядом с кодом.
3. В CI определите SQLX_OFFLINE=true: сборка считывает версионные метаданные и больше не пытается подключиться к реальной базе данных.

Тот же инструмент также управляет миграциями (sqlx migrate add / run / revert) — роль, которую aura-migrations берет на себя отдельно на стороне Aurabase.

Diesel позиционирует себя как «Безопасный, расширяемый ORM и построитель запросов для Rust» (официальный сайт Diesel.rs, по состоянию на 23 августа 2026 г.). В проекте также утверждается, что он «устраняет возможность некорректного взаимодействия с базой данных во время компиляции». Основное отличие от SQLx: Diesel проверяет ваши запросы в самой системе типов Rust, без необходимости подключения базы данных во время сборки.

Официальная страница сравнения Diesel (по состоянию на 23 августа 2026 г.) сама определяет разницу: Diesel «также может проверять части запроса во время компиляции». Это позволяет создавать уже проверенные динамические запросы — IN на векторе Rust, пакетную вставку, условное предложение. SQLx, наоборот, «всегда должен знать весь запрос во время компиляции» для своего макроса: эти три случая остаются за пределами режима 1, рассмотренного выше.

Дизель по умолчанию синхронен; async проходит через отдельный крейт diesel-async. На той же странице сообщается, что команда crates.io замерила прирост в 20% на одной из своих конечных точек после перехода на конвейерную обработку PostgreSQL Diesel-async. На странице указано, что эта функция отсутствует в SQLx и SeaORM. Это заявление Diesel на его собственном сайте об одной конечной точке, а не о независимом измерении, которое мы воспроизвели или обобщили: его следует воспринимать как таковое.

Diesel также включает в себя собственные инструменты миграции и создания схем (официальный README, по состоянию на 23 августа 2026 г.). diesel migration run применяет файлы SQL с поддержкой версий. diesel print-schema восстанавливает модуль Rust schema.rs, описывающий ваши таблицы — ту часть, которую затем использует остальная часть построителя типобезопасных запросов для проверки ваших запросов во время компиляции.

SeaORM описывает себя как «асинхронный и динамический ORM для Rust» (официальный сайт sea-ql.org/SeaORM, по состоянию на 23 августа 2026 г.) с моделью ActiveModel, вдохновленной ORM Ruby/Python/Node. 1-1, 1-N, M-N и отношения с собственной ссылкой, интеллектуальная загрузка путем объединения или загрузчиком данных, сущности, которые могут быть созданы из существующей базы данных с помощью sea-orm-cli. Проверка выполняется во время выполнения, а не при компиляции.

Часто упускаемый из виду момент: SeaORM не всегда является альтернативой SQLx, иногда это два слоя сверху. Генерация SQL осуществляется через sea-query, собственный построитель динамических запросов. Это необязательная зависимость sea-orm 2.0.2 (описание crates.io: «построитель динамических запросов для MySQL, Postgres и SQLite», проверено 23 августа 2026 г.). Выполнение происходит через sqlx/sqlx-core и sea-query-sqlx — три зависимости, объявленные необязательными, активируемые функцией (sqlx-postgresи т. д. — API crates.io, проверено 23 августа 2026 г.). Конкретно: выбор SeaORM со стандартным бэкэндом Postgres означает добавление построителя запросов, а затем сущностей/отношений поверх SQLx, а не его замену.

Миграции следуют одной и той же специальной логике инструментов: sea-orm-cli migrate generate/up/down управляет версиями схемы. sea-orm-cli generate entity затем восстанавливает файлы сущностей из обновленной базы данных — путь туда и обратно от схемы к коду, более близкий к diesel print-schema, чем к динамическому режиму SQLx.

Выбирайте SQLx, если…

• Схема определяется при выполнении (мультиарендный, динамический самоанализ)
• Вы хотите оставаться ближе к SQL, не изучая DSL.
• Непередаваемый родной асинхронный режим

Выбирайте дизель, если…

• Стабильная схема, известная при сборке
• Выдвинута статическая проверка без подключения базы данных ко времени компиляции.
• Приемлема синхронизация по умолчанию или дизель-асинхронная для конвейерной обработки.

Выбирайте SeaORM, если…

• Эргономика ActiveRecord: взаимосвязи, графы объектов
• Сущности, созданные из существующей базы данных
• Еще один уровень абстракции над драйвером SQL — не проблема.

Рабочая область Aurabase Cargo закрепляет sqlx = "0.8" с функциями postgres, runtime-tokio-rustls, uuid, chrono, json, derive и rust_decimal. От него напрямую зависят сервисы aura-db и aura-db-adapters (проверено в репозитории Cargo.toml, 23 августа 2026 г.).

Что важнее, чем строка зависимости: в этом коде нет вызовов макроса sqlx::query! или query_as! (0 вхождений) по сравнению с 532 вызовами sqlx::query()/query_as(), динамической формы. Причина – архитектурная, а не стилевая. Каждый проект Aurabase живет в своей собственной схеме Postgres, которая разрешается при входе в систему с помощью SET LOCAL search_path. Имя запрошенной таблицы поступает в HTTP-запросе, а не в скомпилированном двоичном файле.

Пул соединений сам по себе остается стандартным для SQLx: libs/aura-db-adapters открывает свой пул через PgPoolOptions::new() (проверено в postgres/mod.rs, 23 августа 2026 г.), без специального наложения на этом уровне. То, что является собственностью, находится выше: маршрутизация арендаторов, проверка идентификаторов таблиц, введенных в динамический SQL, и создание предложений WHERE/фильтров, совместимых с PostgREST.

// Целевая схема разрешается запросом, неизвестна при сборке.
sqlx::query("SET LOCAL search_path TO $1, public")
    .bind(project_schema)
    .execute(&mut *tx).await?;

// Таблица/столбцы определяются динамическим слоем REST (совместимо с PostgREST)
let sql = format!("SELECT * FROM {} WHERE {}", table, where_clause);

Статическая модель проверки Дизеля предполагает известный шаблон на момент компиляции двоичного файла. Напротив: один двоичный файл, который обслуживает неограниченное количество шаблонов для каждого проекта, обнаруженный во время выполнения. Генерация сущностей SeaORM основывается на том же предположении о фиксированной схеме. Это не абсолютный приговор SQLx и Diesel в абсолютном выражении — это выбор архитектуры: шаблон, известный при сборке, или шаблон, разрешаемый во время выполнения. Подробные сведения о секционировании схемы для каждого проекта и связанных с ней политиках RLS см. в нашей документации по базе данных и в руководстве RLS.

SQLx, Diesel и SeaORM удовлетворяют три разные потребности, а не три места на одной и той же трибуне. Дизель как можно раньше проверяет заранее известную вам схему. SeaORM сэкономит ваше время на удобстве использования объектов, если вы примете еще один уровень абстракции — часто поверх самого SQLx. SQLx остается самым простым из трех: именно это делает его подходящим для шаблона, который известен только во время выполнения, например многопользовательской маршрутизацииaura-db.

Если вы переносите существующий проект на Postgres и ищете, что действительно изменится в схеме и политиках RLS, наше руководство по миграции Supabase → Aurabase подробно описывает эту тему.