Hi, is it somehow possible to use the AWS RDS service instead of the integrated Postgres DB since the timescaledb extension is used? Or do you have to use Azure or Timescale Cloud now?
Unfortunately TimescaleDBs licensing means AWS RDS cannot offer it as an extension but you could have a dedicated EC2 instance just for timescale or even use timescales cloud offering (which I believe runs inside AWS):
Hi Rich, thanks for your answer!
Hi,
I tried the timescale cloud offering on trial. It fails. The public.realm relation does not exist during the first provisioning during executing the sql-script V20191202_01__Schema.sql
Is there anybody out there who has already experienced this issue and has a solution to it?
I used the (current latest) openremote master commit 6f7ebe0f9d245be90587f14cb8504251a95cc1cd
2023-06-02 09:40:48.299 SEVERE [main ] flywaydb.core.internal.command.DbMigrate : Migration of schema “openremote” to version “20191202.01 - Schema” failed! Changes successfully rolled back.
2023-06-02 09:40:49.318 SEVERE [main ] org.openremote.container.Container : >>> Runtime container startup failed
org.flywaydb.core.internal.command.DbMigrate$FlywayMigrateException: Migration V20191202_01__Schema.sql failed
‘-----------------------------------------’
SQL State : 42P01
Error Code : 0
Message : ERROR: relation “public.realm” does not exist
Location : org/openremote/manager/setup/database/V20191202_01__Schema.sql (/openremote/manager/build/classes/main/org/openremote/manager/setup/database/V20191202_01__Schema.sql)
Line : 214
Statement : alter table ASSET
add foreign key (REALM) references PUBLIC.REALM (NAME)
at org.flywaydb.core.internal.command.DbMigrate.doMigrateGroup(DbMigrate.java:384)
at org.flywaydb.core.internal.command.DbMigrate.lambda$applyMigrations$1(DbMigrate.java:274)
at org.flywaydb.core.internal.jdbc.TransactionalExecutionTemplate.execute(TransactionalExecutionTemplate.java:55)
At this moment, I consider the test as a failure and keep using the own-hosted timescale-postgresql db.
As you probably know DB is used by keycloak and manager containers; manager uses openremote schema by default and keycloak uses public schema.
Our DB setup code adds foreign key constraints linking it to the keycloak public schema; at this time the two services need to share the same DB with keycloak using the public schema.
Not sure how Timescale cloud DB handles schemas?
We can look to break this association.
Hi Rich,
Thank you for the explanation. It makes sense to have a link between keycloak and the manager via public schemas.
I am interested in an affordable serverless option for the database as it stores the state of the application we are trying to build. Having a serverless option for the database reduces the risk of database management, which is the most critical part of the system. Secondly, having a serverless option for the database sells to investors as a risk-reducing measurement. It also allows you to focus entirely on the application development. Taking a serverless solution is more than only a technical consideration.
I will try to make more logging and raise a ticket with Timescale themselves and ask for advise. Hopefully, we will find a solution with the link still in place.