🪄 Открытая альтернатива Firebase — на стероидах PostgreSQL

Платформа, которая даёт всё, чтобы собрать современное веб-, мобильное или AI-приложение — без проприетарных SDK и боли.

Что внутри:
⚙️ Хостинг Postgres с realtime-синхронизацией
🧩 Автогенерация REST и GraphQL API
🔐 Аутентификация и авторизация через JWT
⚡ Edge-функции и серверные триггеры
📦 Хранилище файлов с поддержкой S3
🧠 AI-инструменты: векторные индексы, эмбеддинги, семантический поиск
🪶 Всё open source и доступно для self-host.

По сути это Firebase-опыт, но построенный на «взрослых» open-source технологиях:
PostgreSQL, Elixir, GoTrue, PostgREST, pg_graphql.

Платформа, где можно запустить идею, вырастить продукт и не упереться в чьи-то закрытые лимиты.
#Postgres #OpenSource #Backend #AI #GraphQL #Realtime #FirebaseAlternative

https://github.com/supabase/supabase

⚡️ SQL-прием: EXISTS часто лучше, чем COUNT(*) > 0

Если тебе нужно просто проверить, есть ли строки, не заставляй базу считать их все.

Плохо:

SELECT COUNT(*) > 0
FROM orders
WHERE user_id = 42;

База может пройти по всем подходящим строкам, чтобы посчитать количество.

Лучше:

SELECT EXISTS (
    SELECT 1
    FROM orders
    WHERE user_id = 42
);

EXISTS останавливается сразу, как только нашел первую подходящую строку. Для больших таблиц это может быть заметно быстрее, особенно если есть индекс по условию:

CREATE INDEX idx_orders_user_id ON orders(user_id);

Если тебе нужен ответ “есть или нет”, используй EXISTS. COUNT(*) оставь для случаев, когда реально нужно точное количество строк.

#sql #postgresql #database #backend

🔥 Tailscale полгода ловила «невозможную» порчу SQLite. В итоге нашли баг, который жил в базе минимум 16 лет

В production у Tailscale начали случайно повреждаться SQLite-базы. Никакой стабильной причины: разные шарды, разная нагрузка, иногда между инцидентами проходили недели. За шесть месяцев компания поймала 19 случаев corruption.

После месяцев форензики вместе с core-разработчиками SQLite нашли причину: редкий race condition между записью и WAL checkpoint. При очень точном совпадении по времени SQLite мог решить, что страницы уже перенесены из WAL в основной файл, хотя этого не происходило. Часть данных исчезала, а база становилась повреждённой.

Баг получил название WAL-Reset. По оценке разработчиков SQLite, он существовал минимум 16 лет и был настолько редким, что для тестов пришлось специально писать код, который провоцирует нужную гонку. Tailscale ловила его чаще из-за агрессивного ручного checkpointing.

А дальше стало ещё веселее: версия SQLite 3.52.0 с исправлением обнаружила вторую проблему со stale expression indexes и начала выдавать ложные сообщения о corruption. Релиз отозвали, а фикс WAL-Reset перевыпустили в SQLite 3.51.3.

Редкий пример расследования, где компания полезла искать баг в одной из самых проверенных баз данных мира и действительно нашла его.

🔗 tailscale.com/blog/sqlite-wal-reset-bug

#SQLite #Database #Linux #Backend #Engineering

🔥 Одна строка в конфиге ускорила production-ответ с 126–230 мс до менее чем 9 мс

Paweł Urbanek собрал очень практичный гайд по профилированию Rust, где оптимизации идут не по принципу «что интереснее», а по реальной отдаче.

Из кейсов:

N+1 SQL → 21 запрос превратили в один JOIN, функция ускорилась со 104 до 70 мкс.

Три последовательных HTTP-вызова → tokio::try_join!, итоговое время почти вдвое меньше.

Неправильно настроенный Brotli в maplibre/martin → скорость была всего 27,9 KB/s. Одна правка конфига дала примерно 57x ускорение, а latency упала до <9 мс.

Ещё жёстче кейс с write lock, который держали на всём HTTP round trip. После переноса блокировки P95 для читателей рухнул с 1,11 секунды до 9,42 мкс.

И отдельная классика Tokio: unbounded channel молча накопил 73 сообщения, потому что consumer не успевал. Никакой ошибки, просто медленное движение к OOM.

Полезный порядок из гайда:

сначала SQL и HTTP, потом locks и channels, и только после этого CPU profiling.

Потому что один лишний поход в базу обычно стоит дороже, чем сотни мелких оптимизаций внутри hot loop.

🔗 hotpath.rs/blog/profiling-rust-guide

#Rust #Performance #Profiling #Tokio #Backend