I’m currently working on an analytics platform for my app, and we have chosen to use https://cube.dev as the analytics engine (instead of rolling our own). This is my first time doing something like this hence why I chose an engine like Cube, now, reading thru the documentation it seems like a very good practice to do a Read-Replica of my database (which makes a lot of sense) but I’m not sure how I can make this on Qovery, I had guess i can just go into my AWS console and make the replica by hand and then just configure my backend to route depending on the actions but this does not scale so well, even more counting that we are already working on staging and production environments. So my questions:
Is there any guide on how to properly do replicas while using Qovery? (perhaps a combination of Qovery + AWS on Terraform)
Has anyone deployed https://cube.dev or similar solutions on Qovery? (I will guess it is not something new or super complex, but just for reference :))
Any other recommendations on how to scale a fairly simple analytics platform with multiple sources of data?
There is no guide on how to set up replicas on managed instances using Qovery. However, it’s something we can add. E.g. We can add a property in our database API (via our advanced settings) to make the read replica configurable for your managed database.
Pros:
It’s built-in Qovery
Easy to use and replicate across your environments
Cons:
We need time to implement it
With Qovery + AWS via Terraform
It’s possible via Terraform if you manage your RDS database on your own and interconnect it to your Qovery apps via VPC peering.
Pros:
Implementable now!
You can configure your database as you want and keep it fully flexible
Not as far as I know, but which version of their product do you want to use? Community or Cube Cloud?
Not easy to respond to this question since I am unfamiliar with cube.dev. What does scale mean for you? Do you expect to have a high volume of requests on Cube?
Side note: Even if reading data from a read replica is a good practice, it brings higher tech stack complexity and higher cloud costs. Both are two things to consider. I’d recommend using your production data as a data source until you feel that it can hurt your applications and users.
After reading this I have decided to start simple and not do any read-replica. At least for our current staging environment it will fulfill we will then decide wether we really need it for production.
I had like to have it as automatizable as possible, so a migration to Terraform might be the way to go moving forward, currently we are doing everything manually and we are relying on Qovery’s console ability to replicate environments, so, as we should not be blocked by any provider, moving to Terraform makes even more sense now.
The original idea is to deploy the community Cube.dev enviornment on Qovery
To give more context, we provided the Lifecycle Job as a customizable way to spin up any resources. So, spinning up an AWS RDS instance with a replica via the lifecycle job is possible, and you can set up your replica the way you want.
I really invite you to read the guide I provided above; it explains everything. You must provide your Terraform/Cloudformation/Pulumi/Whatever configuration to create your Replica.