Константин

Эталонный справочник почтовых индексов объектов почтовой связи (Эталонный справочник) разработан Дирекцией технологий и информатизации ФГУП «Почта России». Сопровождение, поддержка в актуальном состоянии и распространение эталонного справочника осуществляются сотрудниками Дирекции.
В эталонном справочнике почтовых индексов объектов почтовой связи представлены данные о почтовых индексах, подчиненности и наименованиях объектов почтовой связи. Данные эталонного справочника являются официальной информацией об индексах объектов почтовой связи ФГУП "Почта России".

vinfo.russianpost.ru/database/ops.html

Не смущает, что на момент вызова второго ALTER таблицы "OBJECTS" еще нет в базе?

H2 database
1. Написана на java и легко интегрируется как внешняя, или Embedded, или Memory БД;
2. Поддерживает много диалектов;
3. Удобство создания;
4. Удобство архивирования (достаточно архивнуть каталог, где расположена БД);
5. Удобство переносимости можно перенести каталог.

Из минусов: если вы меняете версию библиотеки H2 Database - будьте готовы пересоздать базы.

У конструкторов типичный workload - около нуля на большинство площадок и небольшой процент активных. Заворачивать индивидуально каждого в свою БД - сильно утомительно в поддержке. Дожили до 1000 созданных сайтов (что не так уж много если не сказать "вообще крохи") - у вас 1000 баз, что уже весьма дофига. Выкатить в прод новую версию приложения - уже приключение.

Если вы хотите SaaS - т.е. у конечных пользователей прямого доступа в БД нет никакого - то в поддержке сильно проще будет классическая схема шардирования. К тому же у вас данные разных клиентов заведомо по предметной области никак не пересекаются.
- в таблицах специфичных для клиентов вводится site_id и входит в уникальные ключи и прочее счастье ограничений целостности (для postgresql можете дополнительно прикрутить row level security и база будет дополнительно приглядывать)
- отдельно размещается ваш биллинг и управление пользователями, где помимо прочего пишете таблицу соответствия, какой site_id расположен на каком физическом хосте и в какой базе данных (плюс список ro-реплик)
- закешировать соответствие сайта базе можно в каком-нибудь redis и ходить с одного единого пула серверов приложений что сильно проще по масштабированию приложения (если сервер приложения рассматривать как stateless, что опять же сильно проще в поддержке).

В итоге схема позволяет работает с осмысленным числом крупных баз (начиная с одной и вводя новые по необходимости), неактивные сайты мигрировать в архивные базы, горячие от дорогих клиентов - выделять хоть даже в отдельную инфраструктуру. Кстати, фокус с отделением vip-клиента в отдельную инфраструктуру позволяет дать этому клиенту и прямой доступ в базу при необходимости и возможность пилить кастомный функционал именно для него.

clickhouse от яндекса. И с url база хорошо работает, так как изначально для метрики разрабатывалась.

Лови, однополчанин :)
26 Developer Blogs
25 PHP Developers to Follow
18 Go Experts to Follow
20 .NET Developers to Follow
20 Java Developers to Follow
20 Ruby Developers to Follow
18 DevOps Leaders to Follow

Не стоит. Судя по вопросу, программирование - не твоё.