anchor.diff:  [NOTE]
   ====
   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.
  +the extension does not support compiling the embedded database engine into native executables.
   
   Read <<in-memory-databases,Testing with in-memory databases>> (below) for suggestions regarding integration testing.
   ====
  
positive.code: so this is possible as well.
  
  It is important to remember that when configuring H2 (or Derby) to use the embedded engine,
  this will work as usual in JVM mode but such an application will not compile into a native image, as the Quarkus extensions only cover for making the JDBC client code compatible with the native compilation step: embedding the whole database engine into a native image is currently not implemented.
  
  If you plan to run such integration tests in the JVM exclusively, it will of course work as usual.
  
  If you want the ability to run such integration test in both JVM and/or native images, we have some cool helpers for you: just add either `@QuarkusTestResource(H2DatabaseTestResource.class)` or `@QuarkusTestResource(DerbyDatabaseTestResource.class)` on any class in your integration tests, this will make sure the test suite starts (and stops) the embedded database into a separate process as necessary to run your tests.
  
  These additional helpers are provided by the artifacts having Maven coordinates `io.quarkus:quarkus-test-h2` and `io.quarkus:quarkus-test-derby`, respectively for H2 and Derby.
  
  
negative.code: }
  ----
  
  This will allow you to test your application even when it's compiled into a native executable,
  while the database will run in the JVM as usual.
  
  Connect to it using:
  
  [source]
  ----
  quarkus.datasource.db-kind=h2
  quarkus.datasource.jdbc.url=jdbc:h2:tcp://localhost/mem:test
  ----
  
  [[configuration-reference]]
  