Olá Norivan,
É bem comum encontrar esses tipos de BD embarcados em produção dentre os mais diversos níveis de complexidade, porém são utilizados para solucionar situações específicas em arquiteturas, designs e implementações de padrões. No caso, não é aconselhado seguir nesse caminho, já que dentre outros riscos, provavelmente, o requisito principal e básico será garantir o estado dos dados após reiniciar o servidor, o que deve ser trivial, não é?
Ou seja, no frigir dos ovos, se escolher essa opção terá bem mais complicações do que gostaria, confie. Escolha pelo menos um desses standalone mesmo, relacionais, leves e de código aberto como: MySQL ou MariaDB, ... Talvez você pode escolher um outro que não seja relacional, que vai ficar mais leve e simples como como os NoSQL
http://pt.wikipedia.org/wiki/NoSQL.
Banco de dados não se resume a armazenamento de procedures, views ou mesmo qualquer coisa diferente do que comandos DML e DDL. SGDB abstrai da implementação por parte das aplicações de determinadas funcionalidades de gerenciamento extremamente necessárias e que devem ser reutilizadas. No seu caso, você precisará dos dados armazenados para serem consultados posteriormente.
Voltando para os bancos embarcados. Eles foram projetados para resolver situações específicas ou até pontuais onde se precisa de maior confiabilidade e performance. Como por exemplo, a JBoss AS utiliza esse mecanismo para garantir a alta disponibilidade do serviço de mapeamento de serviços, ou Service Registry, para chamadas JNDI dentro do container JEE. Em algumas versões se utiliza o Hypersonic DB ou HyperSQL ou mesmo HSQLDB. Esse possui sérias restrições de performance e integridade, dentre outros comportamentos inesperados em altas escalas de concorrência, podendo até derrubar sua JVM. A própria comunidade jboss desaconselha o uso dele em produção nas versões do JBoss AS. Neste caso indico a substituição para o H2DB, que tem se destacado, inclusive em meus testes de carga e performance. Tem realmente dado conta do recado.