GarrickmaytonИз недостатков я-бы выделил ограничения на размер (в In-memory обычно не кладут
крупные хранилища) и отсутствие внятной политики бекапов.

А кто сказал, что оно только in-memory? У Н2, например, лимит на размер базы данных 4TB, у Derby вообще нет. Есть и транзакции, и backup'ы , и репликация , и кластеризация... всё как у взрослых, только даром. Но у админов, конечно MySQL или PostgreSQL, про Oracle и DB2 вообще не говорю, пользуется большим спросом.
Мы на проекте неоднократно обсуждали заюзать H2 в качестве репозитаря для SonaqQube,
и для прочих внутренних нужд continous integration. В процессе обсуждения звучали
такие фразочки как "...аебали эти ДБА", или "сами будем админить"... e.t.c.

Но девбоксы обычно не бэкапятся так как надо. Есть какая-то базовая политика типа
раз в неделю чето-то там с пользовательских папок... А чинить упавший H2 никто из java-девелоперов
не умеет. Да и когда до дела доходит - то все стрелочкини и спрыгивают в свой уютненький Spring in Action...
В конце концов вернулись обратно в Oracle. Там ничего никогда не теряется. Archivelog
и flashrecovery включен по дефолту. Админы - суровые. Вот как-то так.

mad_nazgulmaytonМы на проекте неоднократно обсуждали заюзать H2 в качестве репозитаря для SonaqQube,
и для прочих внутренних нужд continous integration. В процессе обсуждения звучали
такие фразочки как "...аебали эти ДБА", или "сами будем админить"... e.t.c.

Насчет H2 не знаю, но PostgreSQL админится по принципу "поставил, забыл".
Только по cron'у бекапы выгружай.
Вот только в plain text, из них если что легче БД поднять.
Ну... тут надо исходит из цены той информации которая лежит. Сколько мы готовы
заплатить за сбережение последнего commit-а.

Valery Shiskinmayton,

С 1997 года в конторе, где я работал, развернул Firebird. На момент моего ухода БД содержала порядка 30 млн записей. Меня в конторе давным давно нет. БД до сих пор работает без каких-либо проблем. Где-то раз в неделю стараются сделать backup/restore и все. Никаких аминов. База переносится с сервера на сервер без проблем. Прекрасный визуальный полностью free для России manager. А про надежность, просто найдите в инете почему interbase раньше (сейчас не знаю) широко применялся в армии США. Попробуйте так поработать с Oracle, не говоря уже про цену.
Очень даже может быть. Скорее всего у вас - очень простая система. И 30 млн записей не очень
характеризуют. Скорее важно спросить какой объем этих данных горячий. И сколько конкурирующих
пишущих сессий одновременно выдерживает выша БД.

Valery Shiskinmayton,

Вообще-то термины "простая" или "сложная" скорее относятся к постановке задачи. Не знаю, как в реляционной базе можно сравнивать, что сложнее. А если уж оценивать число одновременно выполняемых транзакций, то уж точно, что Firebird по крайней мере не хуже MySql (кстати, изначально не поддерживала никаких транзакций ), Postgre или H2 (хотя Postgre - это особый случай). И вообще сравнивать СУБД без привязки к конкретной задаче - это не благодарное дело. Сразу найдутся те, кто скажет, что лучше Oracle ничего нет, другие будут уверять что MS Server - самое то и каждый будет прав.
Согласитесь в инженерном споре фраза "уж точно" звучит как-то слабо обоснованно. Как говорил
один математик за "очевидность" в тексте доказательства хочется дать в морду .

Я понимаю что не бывает единой метрики принятия решения о выгоде того или иного продукта.
Но я не просто так спросил про пишущие конкурирующие сессии. Обычно зрелость любой системы
среди DBMS оценивается как готовность поддерживать ACID при конкурирующих 10, 100, 1000 одновременных
сеансов. К слову замечу что среди NoSQL решений этот вопрос часто замыливается и выносится за скобки.

По поводу простоты/сложности. Если у вас БД с 30 млн записей. Но эти 30 млн лежат в одной таблице
то интеллектуальная ценность такой системы не очень высока. Согласитесь это тянет на курсовой проект
студента на тему (например) телеметрии или cбора сведений от "умных вещей" (internet of things).

По поводу PG, H2. Их нельзя писать через запятую. Этим фактом вы просто демонстрируете слабое знание обоих систем.
Первый вариант - от одного из отцов основателей пост-версионности. Широкий набор возможностей. Нативный код
написанный на С/C++. Вполне себе претендует на инструмент импортозамещения. Опенсорц. Можете запилить хоть свой
собственный форк. Часто PG является стандартом де-факто для базы на Linux/BSD.

H2 - это наивная попытка дать реляционный инструмент встраиваемым java-системам. Слабо-конфигурируется.
Лично для меня, как бывшего базовика, сам факт наличия или отсутствия управляющих (control) параметров говорит
очень о многом. Например о том что система - незрелая и не поддающаяся конфигурированию хотя-бы буферного кеша
блоков. Как можно пускать в продуктив систему которая не контролирует явно использование памяти? Сколько она сожрет?
Я не знаю. Я-бы никогда не пускал. Ну или там где нагрузки нет. Логины хранить. e.t.c.

Valery Shiskinmayton,

Вы уж слишком категоричны в суждениях. Насчет H2 хочу сообщить Вам, что разработчик hsqldb и H2 - один и тот же человек.
Офигеть! Как эта информация может оппонировать тому что я сказал?

Это просто забавный файт из серии что и "Волга Впадает в Каспийское море"...

Не зная ни меня ни, как я понимаю, не работав ни с Firebird ни с H2 Вы слишком уж бесцеремонно даете всему оценку.
А я тебе (выше) задавал вопрос. Сколько конкурирующих сеансов-писателей было в твоей системе?

Valery ShiskinНасчет оценки DBMS. это в теории происходит так, как Вы описали. На практике, оценивается все, начиная от сложности решаемой задачи, до толщины бумажника у владельца компании и, последнее чаще доминирует.
В практике на сравнение влияет (на мой взгляд)
1) Готовность команды разработки включиться в разработку "уже завтра".
2) Наличие поддержки каких-то сертификатов безопасности. (Так поступают обычно банки.). Для
них ни новаторство ни трендовость вообще не имеют никакого значения. Главное чтобы какой-нибудь RSA с разрядностью
не ниже чем заданный поддерживался. И чтоб вся бизнес-логика была завернута в яркие фантики наподобие Apache Felix OSGI
или Apache Karaf. Если такого сертификата нет - то можно даже не начинать. Банк скажет что эта разработка не complience
и завернет ее на этапе обсуждения.
3) Стандарты и протоколы (LDAP, SOAP, Blueprint).
4) Лицензии. Деньги.
5) Опции. Сюда как раз идут: Encryption, Olap, Partitioning, Clustering. Все что в презентациях пишут крупными буквами.