Nice writeup! Always appreciate transparency with these sorts of things, as someone who writes a lot of tiny personal projects and sometimes wonders how much I'd have to invest if they ever actually gained any traction. Congrats on having so many users, and good luck on monetization.
For the server instances, I can't imagine 4 CPUs/8 gigs RAM is really needed 24/7, but can imagine it being needed in bursts, and I assume GCP has various "elastic" auto-scaling products for that. Would love to know if your metrics indicate that this is the smallest box you could comfortably run on, or if it's just a best-guess. Could potentially spin down blue-green environments after some set amount of time (once you know a deploy "succeeded"), as well.
For Metabase, I can't find any "system requirements," but I'm not _super_ shocked by the price tag. I've always liked the idea of hosting my own tools instead of relying on some SaaS's free/trial tiers (particularly for things like analytics, logging, or metrics), but a lot of the open source options out there assume you have a pretty hefty box to throw it at. At the same time, I haven't found any better alternative other than just doing ad-hoc analyzing in SQL (using a GUI like Postico).
We run Metabase on a 2GB VM on DigitalOcean, costing $15/month, and using the DO's Postgres cheapest plan (still pretty expensive imo). It's a JVM app so using quite a bunch of memory, 60% atm. So total cost of Metabase is $30 per month. We could definitely just run Postgres on the same VM to get the cost down.
As for web servers, you're totally right. At feeder.co we serve 25 requests / second (on Rails) per VM (we use 4 web servers and one loadbalancer) and we're still database constrained. They are $20 per month and the 4GB 2VCPU "basic" plan.
Hardware is insanely fast nowadays, and it feels like we forget to realise it sometimes.
For a relatively small scale project (5K users) I am running metabase using my production postgres* on a free heroku dyno (Metabase even have a 1-click deploy for this). Takes about 30 seconds to wake up, but the price is unbeatable. I don't get any of the scheduled features ofc. Would recommend for keeping costs low.
*using a heroku standard-0 db, so $50/mo with relatively good performance
Yes, the server instances are definitely too large. I was previously running on 2 instances that were half the size and ran into some problems which I thought I could fix by increasing specs. Turns out the problems were not related to specs and now I'm stuck with the instance size (on DigitalOcean you can only up-size not down-size)
I use Postico too, but don't have enough SQL chops to get the answers I need.
These are all my suggestions, I would also add look for ways to spread out tasks to other smaller VMs - the general pricing is +$5 "per" ($5 per +1 vCPU, $5 per +2G vRAM), a $5/$10 webserver only handle static asset delivery, then apps on middle tier app servers at $15/$20 would give better fault tolerance and spread out the load and still keep blue/green.
You can downsize, just start at a small size and don't increase storage (choose ram and cpu only when upgrading), then you can resize smaller if you want.
Getting to a place where you don't care as you can rotate in new instances at whatever spec you want is even better though.
As a data point, we're using Redash (https://github.com/getredash/redash/), an alternative to Metabase, in a VM on Digital Ocean. It's a US$15 VM (2 cpu, 2GB ram) and seems to be fine. That's using a PostgreSQL instance running on the same VM, and nothing seems to be unhappy.
The graphs it generates are used both publicly (auto-updating):
... and we have a bunch more private graphs and dashboards for metrics.
Everything is close to instant in responsiveness, apart from the "public" stats above. Those take some time to display purely on the browser side, as they feed way too much data to a browser for easy rendering. (will be fixed at some future point). ;)
Probably the only down side to Redash is a need to understand SQL. That can start out pretty simply though. :)
Unlike AWS GCP has fewer options and I would argue nothing would fit out of the box. App engine is a PaaS that has various limitations and constraints that can take significant amounts of dev time and customer support time to get through. Spot instances require ops work, as would something like GKE combined with horizontal autoscaling via kubernetes. Their best bet would be to identify hot paths in the code base and move them to cloud functions at the cost of latency then scaling down the servers.
Often in cloud computing it’s dev time, ops time, cost savings, choose one.
> App engine is a PaaS that has various limitations and constraints that can take significant amounts of dev time and customer support time to get through
What limitations/constraints of App Engine have you run into?
For the server instances, I can't imagine 4 CPUs/8 gigs RAM is really needed 24/7, but can imagine it being needed in bursts, and I assume GCP has various "elastic" auto-scaling products for that. Would love to know if your metrics indicate that this is the smallest box you could comfortably run on, or if it's just a best-guess. Could potentially spin down blue-green environments after some set amount of time (once you know a deploy "succeeded"), as well.
For Metabase, I can't find any "system requirements," but I'm not _super_ shocked by the price tag. I've always liked the idea of hosting my own tools instead of relying on some SaaS's free/trial tiers (particularly for things like analytics, logging, or metrics), but a lot of the open source options out there assume you have a pretty hefty box to throw it at. At the same time, I haven't found any better alternative other than just doing ad-hoc analyzing in SQL (using a GUI like Postico).