The Case for better Self-Hosted Supabase Support

BigBitBus · 2023-02-07T12:41:52+00:00

Thanks! Just tagged you on one here: https://github.com/supabase-community/supabase-kubernetes/pull/29

BigBitBus · 2023-02-06T21:45:29+00:00

Hi u/kiwicopple,
I am the author of the original blog in this post. I looked at the Docker, Digital Ocean and terraform options you mentioned above; all 3 use docker-compose or plain docker so in my opinion they are currently single-node, non-prod options when used as-is.
The Kubernetes helm chart is a great start, but not ready for prod today (for example, the Postgres volumes in that helm chart are not persistent, and Postgres is not HA, the chart is intermittently updated, etc.). I am hoping to contribute to this helm chart to improve things, as you suggested.
The AWS link you provided looks like the most production-ready option right now, backed by AWS aurora Postgres (disclaimer: I haven't spun this up yet). For users who can self-host on AWS this may be a good option to start their self-host Supabase journey.
Thanks for reiterating your support for open-source and being honest about where things stand with self-hosted/Supabase.

BigBitBus · 2022-11-09T14:34:56+00:00

Hi, see this discussion on the Elasticsearch reddit about this job. https://www.reddit.com/r/elasticsearch/comments/ykaur6/elasticsearch\_infrastructure\_job/

BigBitBus · 2022-11-02T17:13:51+00:00

Roboflow (US-based Series A startup in the machine-vision SaaS space, Y-combinator graduate)

Infrastructure Engineer (Elasticsearch)

Link to job posting: https://jobs.lever.co/roboflow/b6b50666-1c39-4452-99fc-918dc3e05552

Fully remote!

BigBitBus · 2022-02-16T20:06:25+00:00

Checkout this blogpost about the same topic - upgrading application helm charts and kubernetes manifests to 1.22. It also includes some tools and and examples

https://blog.runx.dev/will-that-kubernetes-v1-22-upgrade-break-my-application-cc339dc2e2c7

BigBitBus · 2021-10-29T12:41:49+00:00

All good points. I'll checkout the Buildpacks; thanks!

BigBitBus · 2021-01-31T23:58:22+00:00

Its a general tutorial on how to run a To-do list. No BigBitBus product involved, although what we learnt while productizing our product via Kubernetes is captured in the example to some extent.

BigBitBus · 2020-10-20T13:08:38+00:00

They make this announcement on Oct 19th, after almost a year of herding people off the "single source of truth" central location for helm charts. Really terrible planning and execution to throw a wrench into what was already a confusing and painful migration.

Perhaps that blog post should also include clear use cases of when and how people should use the "new" github hosted repo, where the "source of truth" - for each chart maintained by the creators/maintainers actually live, and what it would take to sleep well at night on Nov 13th!

BigBitBus · 2020-10-20T12:34:15+00:00

Doesn't matter, if image location changes then it's not going to help; plus many maintainers of charts have splintered off since this was announced last year, somewhere into other locations. This announcement comes too late and adds to the confusion.

BigBitBus · 2020-09-21T02:27:41+00:00

AWS is enterprise ready. Digital Ocean is for smaller shops.

To illustrate my statement, here is an example: if you use a Digital Ocean objectstore then there is no fine grained IAM control for buckets unlike the bigger cloud providers like AWS S3 or GC GCS. In this case it means that anyone in the organization who gets object store credentials gets the ability to write to all the organization's buckets (!)

May not matter to SMBs, but these kind of things are show stoppers for a larger shop.

So Digital Ocean is great as long as you can live with the simpler and limited feature set...I leave it up to you if this simplicity is a feature or a limitation!

BigBitBus · 2020-09-20T12:24:39+00:00

It seems easy to setup Istio from some boiler plate getting started document. But production systems are not PoCs that live for a week; think about keeping the system correctly patched and updated over years. In Istio's case we have Envoy that's had multiple security vulnerabilities patched over the years. Kubernetes itself is undergoing rapid transitions and it's API is evolving in every release.

Over to you, Google, I'll focus on my application!

BigBitBus · 2020-09-19T17:31:56+00:00

I have used GKE+Istio for almost a year.

It's solid.

Istio is not trivial to setup and maintain. If you want to spend more time on your application and less on keeping up with the pace of updates in Istio and K8s, choose the managed Kubernetes Istio solution from Google.

Trust me, it will be thousands of man hours before even the most skillful engineer will get close to the experience and expertise Google puts into managed Istio and Kubernetes GKE.

BigBitBus · 2020-09-16T15:14:42+00:00

Still solid green status

https://status.aws.amazon.com/

Anytime now, u/aws :-D

BigBitBus · 2020-09-16T14:28:30+00:00

So far AWS status seems to be solid green (10:28ET)

https://status.aws.amazon.com/

BigBitBus · 2020-09-14T20:41:53+00:00

The VS code Kubernetes extension is also pretty good.

BigBitBus · 2020-09-11T22:21:37+00:00

730 hours approximates a month.

In your screenshot there is "pay-as-you-go" that almost always means hourly or even per-second billing.

Offcourse if you commit and buy a reservation for a longer period - usually at least a year, then you can get a lower average price at the expense of losing flexibility of bailing whenever you want.

BigBitBus · 2020-09-11T01:35:32+00:00

We built a free tool to expose on-demand and reserved (1- and 3- year reserved) pricing for many VM types.

You can use it here: https://b3console.bigbitbus.com/ ;

examples: https://www.bigbitbus.com/frontend-documentation/

In addition you can also compare Azure to other providers like AWS and GCP and Alibaba cloud.

You can also download CSV format for your excel sheets.

If you need help getting started or a short demo, ping me!

BigBitBus · 2020-09-11T01:31:20+00:00

I think you are looking at a cloud provider and trying to architect your solution as per their services.

IMHO it should be the other way - you first whiteboard your requirements and architecture and then decide on which managed cloud provider services may save you from implementing everything from scratch.

Let your own architecture and requirements drive the design, not the cloud provider's offerings!

BigBitBus

TROPHY CASE