Surya OCR выглядит очень мощно для открытой OCR-модели.

Что выделяется:

→ менее 1 млрд параметров
→ поддержка 91 языка
→ до 5 страниц в секунду на RTX 5090
→ работает на CPU, GPU и Apple MPS
→ 83.3% на бенчмарке olmOCR, один из лучших результатов среди моделей до 3B параметров

Surya OCR относится к классу Document Intelligence-моделей. Она не просто извлекает текст с изображения, но также умеет работать со структурой документов: PDF, сканами, таблицами, многостраничными документами и сложной вёрсткой.

Подходит для задач:

• OCR документов и PDF
• оцифровки книг и сканов
• RAG-пайплайнов
• обработки счетов и форм
• извлечения данных из таблиц
• подготовки датасетов для LLM

100% open source.

👉 @SQLPortal

Обновить одну таблицу, используя значения из другой таблицы через прямое JOIN-соединение в 26ai:

UPDATE <target_tab>
SET <target_col> = <source_col>
FROM <source_tab>
WHERE <join_condition>

Такие JOIN-соединения также можно использовать в операторах DELETE.

👉 @SQLPortal

Скиллы AI-агентов представляют собой набор инструкций в Markdown, которые объясняют, как выполнять определённую задачу.

Kris Rice создал библиотеку из более чем 100 скиллов для работы с Oracle AI Database, включающую практические примеры, лучшие практики и распространённые ошибки.

Получить их можно здесь: https://github.com/oracle/skills

👉 @SQLPortal

Я сократил расход токенов в Claude Code вдвое с помощью одного файла.
Замерял результат в течение недели.

Секрет прост: научить Claude выбирать модель в зависимости от задачи.

Haiku для массовых механических задач.
Sonnet для исследований и анализа.
Opus только там, где действительно требуется сложное рассуждение.

До этого токены тратились без разбора на любые задачи.

После настройки результат остался тем же, а расход снизился примерно вдвое.
Схема состоит из трёх частей.

1. Блок делегирования задач
Вы задаёте правило, по которому Claude создаёт субагентов и выбирает самую дешёвую подходящую модель:
→ Haiku: рутинные задачи без необходимости принимать решения
→ Sonnet: исследования, изучение кодовой базы, анализ и обобщение информации
→ Opus: только для реального планирования и сложных компромиссов

Два важных ограничения:
• Haiku никогда не создаёт собственных субагентов. Если это понадобилось, задача была плохо декомпозирована.
• Максимальная глубина вложенности — два уровня (родитель → субагент → ещё один уровень).
Если субагенту требуется более сильная модель, он возвращает задачу родителю, а не повышает уровень самостоятельно.

2. Блок предпочтительных инструментов

Вы учите Claude сначала выбирать самые дешёвые инструменты:
→ WebFetch для публичных веб-страниц
→ agent-browser CLI для динамических страниц и сайтов с авторизацией (примерно на 82% меньше токенов по сравнению с инструментами на основе скриншотов)
→ Конвертация PDF в текст вместо использования инструмента Read

Если Claude постоянно повторяет один и тот же шаблон действий, вы просите его оформить этот процесс как переиспользуемый инструмент.

3. Две строки в settings.json

"CLAUDE_CODE_DISABLE_1M_CONTEXT": "1"

Не позволяет загружать огромные контекстные окна, которые часто не нужны.

"CLAUDE_AUTOCOMPACT_PCT_OVERRIDE": "80"

Запускает автоматическое сжатие контекста при заполнении на 80%, а не после полного заполнения.

Только эти две настройки экономят токены в каждой сессии.
Вся настройка занимает около двух минут.
А экономия начинает накапливаться с каждой следующей задачей.

👉 @SQLPortal

Dolt — это SQL-база данных с полноценным Git-подобным контролем версий для данных.
Можно делать ветки, мержить изменения, форкать и клонировать не только код, но и сами данные.

• Подключение через MySQL-протокол, чтение и запись версионируемых данных обычным SQL
• Импорт CSV, коммиты изменений, push, pull и merge через привычные Git-команды
• Публикация баз на DoltHub или самостоятельный хостинг через DoltLab
• Используется как слой памяти для AI-агентов в multi-agent и multi-machine workflow

Если вам когда-нибудь хотелось сделать git checkout, git diff или git merge для базы данных, Dolt решает именно эту задачу.
Посмотреть проект можно здесь: https://github.com/dolthub/dolt

👉 @SQLPortal

Устали постоянно получать:

CREATE ...

ORA-01031: insufficient privileges

при создании объектов?

В Oracle AI Database 26ai достаточно выдать одну роль:

GRANT db_developer_role TO ...

После этого пользователь сможет создавать все стандартные объекты базы данных.

👉 @SQLPortal

Supabase и Firebase забрали все ваши деньги?

Butterbase только что открыл исходный код. Полностью open-source бэкенд с нативной поддержкой AI:

- Postgres с RLS
- Auth и OAuth
- Хранилище
- Functions
- AI Gateway
- MCP Server (чтобы ваши агенты могли использовать бэкенд как полноценный набор инструментов)

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

Всё доступно через инструменты.

Можно развернуть самостоятельно или использовать их managed-версию.

РЕПО ↓
https://github.com/butterbase-ai/butterbase

👉 @SQLPortal

Большинство AI-кодинг-агентов знают SQL.

Намного меньше из них понимают базы данных.

PlanetScale выложили Database Skills. Это набор skills для AI-агентов, которые работают с MySQL, Postgres, Vitess и Neki.

Вместо одного огромного промпта:
→ отдельный skill для MySQL
→ отдельный skill для Postgres
→ отдельный skill для Vitess
→ отдельный skill для Neki

Что умеет:
• проектирование схем
• индексы и оптимизация запросов
• транзакции и блокировки
• MVCC, VACUUM и WAL в Postgres
• шардинг через Vitess
• Online DDL и VReplication
• диагностика медленных запросов

Установка:

npx skills add planetscale/database-skills

или в Cursor:

/add-plugin database-skills

Мне нравится сама идея.
Сейчас многие используют агентов как очень умный автокомплит. А вот заставить агента понимать, почему этот индекс плохой, почему VACUUM отстаёт или почему шардирование сломает запросы через полгода, уже гораздо интереснее.

Open source. MIT License. GitHub доступен всем.

👉 @SQLPortal

У Claude Code довольно элегантная структура проекта: одна папка .claude/, в которой живёт всё, что связано с агентом.

👉 @SQLPortal

Только начинаете знакомство с Oracle AI Database?

Anders Swanson показывает, с чего начать.

Что входит в руководство:

• запуск бесплатной базы данных в Docker
• установка необходимых инструментов для разработки: расширения SQL Developer для VS Code и CLI-интерфейса SQLcl
• подборка бесплатных материалов для изучения Oracle AI Database и экосистемы Oracle

Подойдёт тем, кто хочет быстро поднять локальное окружение и начать работать с Oracle без лишней настройки.

👉 @SQLPortal

Любимый паттерн для “последняя запись на группу” в Postgres — DISTINCT ON.
Да, он Postgres-specific. Нет, он не из SQL Standard. Зато для этой задачи он читается почти идеально.

Есть таблица заказов:

CREATE TABLE orders (
  id          bigint PRIMARY KEY,
  customer_id int,
  status      text,
  created_at  timestamptz
);

Старый классический вариант:

SELECT o.*
FROM orders o
INNER JOIN (
  SELECT customer_id, MAX(created_at) AS latest
  FROM orders
  GROUP BY customer_id
) latest ON o.customer_id = latest.customer_id
        AND o.created_at  = latest.latest;

Работает, но есть нюансы.
Таблица читается два раза: сначала ищем MAX(created_at) по каждому customer_id, потом джойнимся обратно за полной строкой.

И ещё хуже: если у одного клиента два заказа с одинаковым created_at, запрос может вернуть две строки. Нужен tie-breaker.

В Postgres проще так:

SELECT DISTINCT ON (customer_id)
  customer_id, status, created_at
FROM orders
ORDER BY customer_id, created_at DESC;


DISTINCT ON (customer_id) оставляет первую строку для каждого клиента после сортировки.
То есть ORDER BY customer_id, created_at DESC сначала кладёт свежий заказ клиента наверх, а DISTINCT ON забирает его.

Чтобы это реально летало, добавляем индекс:

CREATE INDEX ON orders (customer_id, created_at DESC);

Теперь Postgres может идти по уже отсортированному индексу и не делать отдельную сортировку.
На небольшом тесте с 100k строк и 20k customer_id получилось так:
Без индекса:
• MAX + self-join: 32.92ms
• DISTINCT ON: 34.75ms
• ROW_NUMBER(): 38.68ms
С индексом (customer_id, created_at DESC):
• DISTINCT ON: 15.99ms
• ROW_NUMBER(): 25.36ms
• MAX + self-join: 38.01ms

Главный вывод: для “одна последняя строка на группу” в Postgres я первым беру DISTINCT ON.
Если нужно не одну строку, а top N строк на группу, тогда уже ROW_NUMBER():

SELECT customer_id, status, created_at
FROM (
  SELECT *,
    ROW_NUMBER() OVER (
      PARTITION BY customer_id
      ORDER BY created_at DESC
    ) AS rn
  FROM orders
) ranked
WHERE rn = 1;


DISTINCT ON — для простого “последний на группу”.
Window functions — когда нужна гибкость.

👉 @SQLPortal