Hi Andreas, Thanks for asking. I realized I have some unstated goals. Here are my thoughts:
On Saturday, April 24, 2021 at 12:22:30 AM UTC-7 [email protected] wrote: > > a) mount the cloud storage per SSHFS and access the normal DB file > This configuration would still retain an undesirable (to me) characteristic of a traditional RDBMS, mainly, that you have one node (running H2) that acts as a bottleneck for all data access. Here I have an unstated requirement: I want the ability for some consumers to "backdoor" and read the data in the cloud backing store directly through native APIs without going through H2. > b) or start the H2 server in the cloud and access it via TCP > > This approach suffers of the same limitation above and also one more: I don't want to run an additional server. > What are the Pros of your ideas and what are the Cons of the "traditional" > approach (despite having no buzzwords in the description). > > Traditional approach: - I have some small legacy apps running on mysql. These apps already exist so it's not a matter of debate. My ideas: - I don't want to rewrite the apps to a native cloud API. - I actually like SQL, and I love Java SQL APIs such as JDBC, JdbcTemplate, and Hibernate.. - But I don't like database servers. - So my idea is to move to embedded H2 with cloud backing store and get rid of the database servers, while keeping SQL, JDBC, JdbcTemplate, and Hibernate. -- You received this message because you are subscribed to the Google Groups "H2 Database" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/h2-database/7fc188c0-b2c3-44f0-80b3-eb4c975763b3n%40googlegroups.com.
