search

quarkusio / quarkus

Quarkus: Supersonic Subatomic Java.
https://quarkus.io
Apache License 2.0
13.44k stars 2.58k forks source link

Support In-Memory database for native images #6320

Closed michael-schnell closed 1 month ago

michael-schnell commented 4 years ago

Currently the QUARKUS - DATASOURCES documentation states: "The H2 and Derby databases can normally be configured to run in "embedded mode"; the extension does not support compiling the embedded database engine into native images"

As there are several use cases for using in-memory databases like H2, Derby, HSQLDB, and SQLite also in production (not only for tests), the Quarkus extensions for H2 and Derby should support "embedded mode".

thorstenhirsch commented 3 years ago

Current status still is "embedding the whole database engine into a native executable is currently not implemented". Any plans to implement this feature?

gsmet commented 3 years ago

No. We don't really have plans for it.

But if anyone wants to give it a try, it will probably require some GraalVM surgery.

geoand commented 3 years ago

What's the use case for this?

I am fairly certain that the use of DevServices (which can start the necessary database as part of a different process) in all forms of tests should cover the need for this.

michael-schnell commented 3 years ago

In case you have hundreds of unit tests that require a database to run, it's not always desired to run them really against the real (target) database. An in-memory DB is often just "good enough" to achieve the test goal, even if there might be slight differences between the in-memory and the production DB. This risk can easily be covered by having a smaller set of integration tests that use the production DB.

If you use always the production DB, the unit tests a) might interfere or require complicated setup/cleanup for each test when using only one instance b) are slow, because you have to start & stop separate instances of the DB in between the tests (for example using test containers)

With an in-memory DB you can have a DB instance "per unit test class" or even per "unit test method" that is fully separated from all the the other tests. Creating an in-memory database and shutting it down after the test is far quicker than doing this with a real database. No need for any programmed setup/cleanup or transactional rollback in your test code.

michael-schnell commented 2 years ago

There are also some use cases for production where an in-memory database is a good choice. If you think about stateless cloud services where the whole data fits into memory, there can be a huge performance gain using something like HSQL instead of a traditional external database like MariaDB.

ckyara commented 2 years ago

Can we have a working code to use in memory database (H2) in production env as i am facing issue with the same?. Getting exception that 'java.sql.SQLException Driver does not support provided URL: test'

URL : jdbc:h2:mem:default;MODE=Oracle;DB_CLOSE_DELAY=-1

yrodiere commented 1 month ago

Latest status, straight out of the documentation:

Support and limitations

Embedded databases (H2 and Derby) work in JVM mode. For native mode, the following limitations apply:

  • Derby cannot be embedded into the application in native mode. However, the Quarkus Derby extension allows native compilation of the Derby JDBC client, supporting remote connections.
  • Embedding H2 within your native image is not recommended. Consider using an alternative approach, for example, using a remote connection to a separate database instead.

So H2 embedded should technically work, though it's still not recommended.

Should we close this?

geoand commented 1 month ago

Should we close this?

+1