Один засновник тримає глобальну тендерну платформу на AlloyDB
Стартап Lucius AI обробляє понад 210 000 тендерів з Британії, ЄС, Індії, Австралії й інших ринків на AlloyDB for PostgreSQL — без окремого DBA. Перевівши пошук на індекс ScaNN, засновник Давор Єрковіч скоротив затримку запиту з 1,14 секунди до 24 мілісекунд — у 47 разів.
AI-агент підключений через MCP Toolbox for Databases з обмеженими правами: SELECT по схемі, UPDATE на одну таблицю, без DROP, DELETE і TRUNCATE. Він сам аналізує запити, шукає індекси, розслідує інциденти безпеки за логами й щоранку перевіряє свіжість даних з усіх 13 джерел — роботу окремої команди.
Lucius AI оцінює тендерні можливості для компаній, що подаються на державні контракти: платформа обробляє повідомлення про закупівлі з Великої Британії, ЄС, США, Канади, Австралії, Нової Зеландії, Індії, Сингапуру, а також донорські тендери Світового банку в Африці та Азії. Gemini аналізує тендерну документацію і готує матриці відповідності вимогам, рекомендації щодо участі та чернетки заявок із посиланнями на першоджерела — раніше на це йшли дні ручної перевірки документів і залучення зовнішніх консультантів.
Одна база замість трьох окремих систем
Замість окремих реляційної бази, векторного сховища і системи логів усі дані Lucius AI лежать в одній AlloyDB for PostgreSQL: каталог тендерів, метадані документів, журнали аудиту й векторні ембедінги. Це дає єдиний графік резервного копіювання і централізоване управління доступом. Автентифікація повністю на Cloud IAM: сервіси підключаються через сервісні акаунти Google Cloud, прив'язані до ролей бази з обмеженими правами — паролі до бази в коді застосунку не зберігаються. Відновлення на точку в часі й резервне копіювання виконує сама AlloyDB, без окремих процедур disaster recovery.
Платформа працює у двох регіонах: європейський розгортається на Cloud Run, а австралійський має власний кластер AlloyDB з керованими клієнтом ключами шифрування (CMEK) — це вимога клієнтів, пов'язаних з оборонною сферою. Коли команда перебудовувала семантичний індекс, ембедінг 115 820 записів моделлю Gemini зайняв 10,6 хвилини і коштував близько трьох доларів API-використання; далі свіжість векторів підтримує автоматичне оновлення ембедінгів усередині AlloyDB. Ранжування результатів пошуку виконується прямо в базі функцією ai.rank із середньою затримкою 77 мілісекунд — без окремого мікросервісу для реранжування.
Права AI-агента прописані наперед, а не «за замовчуванням»
Агент підключений через відкритий MCP Toolbox for Databases (готовий сервер alloydb-postgres) під окремою PostgreSQL-роллю: SELECT по всій схемі й UPDATE лише на одній операційній таблиці. DROP, DELETE, TRUNCATE з цієї ролі прибрані повністю — фізично неможливо стерти чи знищити дані, навіть помилково.
У межах цих прав агент щодня виконує чотири типи задач:
- Аналітика на вимогу: когорти утримання, воронки активації, покриття каталогу по країнах — без окремих дашбордів і аналітичних конвеєрів
- Оптимізація продуктивності: перевірка планів запитів і аналіз індексів — саме так з'явилась рекомендація перейти на ScaNN
- Розслідування інцидентів: після зовнішньої спроби сканування безпеки агент розібрав журнали аудиту, за кілька хвилин відновив хронологію запитів і підтвердив, що ізоляція даних між клієнтами не порушена
- Контроль якості даних: щоранку перевіряє свіжість (watermarks) надходжень з усіх тринадцяти джерел закупівельних даних
Команда формулює це як прогресивну структуру дозволів: почати з доступу лише на читання, розширювати права по мірі потреби, а деструктивні операції залишати виключно за людьми-адміністраторами.
Де цей підхід не спрацює автоматично
Модель «один оператор» тримається на тому, що права агента звужені до конкретної ролі ще до підключення, а не обмежуються постфактум. Для клієнтів, пов'язаних з оборонною сферою, компанія взагалі не поклалась на спільну консолідовану базу — розгорнула окремий кластер з CMEK в іншому регіоні. Чим чутливіші дані, тим менше сенсу тримати їх в одному спільному контурі з AI-агентом, навіть якщо права обмежені.
Індексна рекомендація й майбутні автоматизації в матеріалі не впроваджувались наосліп. Перед міграцією на ScaNN агент спершу протестував план запиту й лише потім підготував міграцію індексу. Автоматичні ембедінги в AlloyDB AI команда спершу перевірила на всьому каталозі (ai.initialize_embeddings) і тільки після цього запустила щотижневе оновлення (ai.refresh_embeddings). Колончастий рушій з автоколонаризацією за добу сам визначив і закешував у пам'яті 40 найчастіше запитуваних колонок у чотирьох таблицях, прискоривши звітні запити без окремого аналітичного сховища — але це результат спостереження за поведінкою бази, а не сліпого довір'я до першої-ліпшої оптимізації.
Загальну вартість інфраструктури AlloyDB чи економію від відмови від окремого DBA матеріал не наводить — відома лише вартість одноразової переembedизації каталогу.