kiwicopple

I guess the term “Serverless” is pretty ambiguous, but since this originated from AWS Lambda (firecracker) and that’s the same primitive as Fly.io then it seemed fitting. You can scale up/down compute and snapshot memory for fast startups

The other tricky thing is data: there are several ways to handle this. Since Tigris has a lot of the data replication features that Postgres would traditionally handle then it looks promising. That said - it comes with tradeoffs that you point out (transfer costs) but these are also costs that you’d pay for postgres replication. I’ll try benchmark some of these costs and compare them across several implementations. At this stage I just wanted to get an MVP working: the harder stuff is still ahead

Thanks for your comment - a lot of good points

The “scale to zero” aspects mean that it’s useful for very infrequently accessed applications

Once I have experimented with Tigris’ global data replication then it could be useful for a distributed user-base doing a lot of reads. The idea is that you can point a fresh postgres instance to the S3 bucket for read access (rather than keeping a hot standby using Postgres native replication)

Agreed, this is a problem with twitter not Firefox

> We will probably be contributing to iceberg-rust to make it work with pg_lakehouse

That's great news, thanks for your contributions to open source (here, and all the other extensions)

Neat that you plan to support both Delta Lake and Apache Iceberg

I'm curious about HN's position between these two formats? I'm having a hard time deciphering which might be the industry winner (or perhaps they both have a place, no "winner" necessary)

it's 1 - you pay us, we pay AWS.

In the future we will likely provide "bring your own s3" (2)

we might be able to achieve the same thing now with our S3 Wrapper:

https://supabase.github.io/wrappers/s3/

Yes, we have a vastly different architecture[0] from Pocketbase. We choose individual tools based on their scaling characteristics and give you the flexibility to add/remove tools as you see fit.

I doubt we can ever squeeze the "supabase stack" into a single binary. This undoubtedly makes things more difficult for self-hosters. Just self-hosting Postgres can be a challenge for many. We will trying to make it easier, but it will never be as simple as Pocketbase.

[0] https://supabase.com/docs/guides/getting-started/architectur...

Unfortunately there isn't a way to prove our intentions to remain open source

That said, I think Supabase is much more de-risked from this happening because we aim to support existing tools with a strong preference of tools that are controlled by foundations rather than commercial entities. For example, 2 of the main tools:

- Postgres (PostgreSQL license)

- PostgREST (MIT license)

Every tool/library/extension that we develop and release ourselves is either MIT, Apache2, or PostgreSQL

I checked with the team - it was already in the self-hosted version.

There are some guides for using this in the CLI docs:

https://supabase.com/docs/guides/auth/auth-hooks#local-devel...

(I'll find a way to consolidate these docs so the work across CLI + docker-compose)

i believe the docker image ID on the docker-compose hasn’t been updated to the latest stable version. I’ll make a PR later when I’m at my computer (or anyone else is welcome to and I can review/merge)

We sponsored/invested in them previously (over half a million USD). The benefit of acquiring is that the team can focus on the technology rather than the business/operations around it.

I hope this is the best outcome for the industry. If there are other postgres companies that would like to use oriole, feel free to reach out. It’s 100% open source and we’d love more design partners

(FYI: I saw a deleted comment that this requires a restart: the same is true on the platform)

> mapping JS entities using the JS DB API makes it hard to use camelcase field names due to PG reasons I can't recall

Postgres requires you to "quoteCamelCase". There are some good JS libs to map between snake case and camel case. FWIW, I like a mix of both in my code: snake_case indicates it's a database property, and camelCase indicates its a JS property. Try it out - it might grow on you :)

thanks for the links

> https://github.com/orgs/supabase/discussions/4444

This discussion is about configuration: self-hosters configure configure their services in code[0], using .env vars / docker-compose.yml and should be checking it into source control. Self-hosters are not missing any functionality - the opposite actually: we have a subset of configuration items available on the platform

I get that it's different to the platform, but it's (IMO) the more "correct" way - all configuration should be version controlled

> https://github.com/orgs/supabase/discussions/4421

This one is about Auth providers. They are also configuration: https://github.com/supabase/auth?tab=readme-ov-file#configur...

[0] Configuration in code: https://supabase.com/docs/guides/self-hosting/docker#configu...

[1] Terraform: https://supabase.com/docs/guides/platform/terraform

> neutered

Can you share more? There is nothing missing, it’s all the same code that we run in production (besides some login changes to keep it decoupled from the platform)

Thanks for the recommendations - I’ll see what this would involve

Yes, we made it an official library this week: https://supabase.com/blog/supabase-swift

we (the founders) control the board

just a small elaboration:

You can serve HTML content if you have a custom domain enabled. We don't plan to do anything beyond that - there are already some great platforms for website hosting, and we have enough problems to solve with Postgres

Oriole are joining to work on the OrioleDB postgres extension. That's slightly different to this release:

- This: for managing large files in s3 (videos, images, etc).

- Oriole: a postgres extension that's a "drop-in replacement" for the default storage engine

We also hope that the team can help develop Pluggable Storage in Postgres with the rest of the community. From the blog post[0]:

> Pluggable Storage gives developers the ability to use different storage engines for different tables within the same database. This system is available in MySQL, which uses the InnoDB as the default storage engine since MySQL 5.5 (replacing MyISAM). Oriole aims to be a drop-in replacement for Postgres' default storage engine and supports similar use-cases with improved performance. Other storage engines, to name a few possibilities, could implement columnar storage for OLAP workloads, highly compressed timeseries storage for event data, or compressed storage for minimizing disk usage.

Tangentially: we have a working prototype for decoupled storage and compute using the Oriole extension (also in the blog post). This stores Postgres data in s3 and there could be some inter-play with this release in the future

[0] https://supabase.com/blog/supabase-aquires-oriole

> Parquet. But, I'd also like to store PDFs, CSVs, images

yes, you can store all of these in Supabase Storage and it will probably "just work" with the tools that you already use (since most tools are s3-compatible)

Here is an example of one of our Data Engineers querying parquet with DuckDB: https://www.youtube.com/watch?v=diL00ZZ-q50

We're very open to feedback here - if you find any rough edges let us know and we can work on it (github issues are easiest)

are there any specific integrations that you want? (eg: which companies?)

we have a built-in CDN[0] and we have some existing integrations for transactional emails [1]

[0] Smart CDN: https://supabase.com/docs/guides/storage/cdn/smart-cdn

[1] Integrations: https://supabase.com/partners/integrations

that's not how this works. files are stored in s3, metadata in postgres

> I can utilize any CDN provider that supports S3. Like bunny.net

Bunny is a great product. I'm glad this release makes that possible for you and I imagine this was one of the reasons the rest of the community wanted it too

> But more attention to basic features and little details

This is what we spend most of our time doing, but you won't hear about it because they aren't HN-worthy.

> no direct support for metadata

Fabrizio tells me this is next on the list. I understand it's frustrating, but there is a workaround - store metadata in the postgres database (I know, not ideal but still usable). We're getting through requests as fast as we can.

self-hosting docs are here: https://supabase.com/docs/guides/self-hosting/docker

And a 5-min demo video with Digital Ocean: https://www.youtube.com/watch?v=FqiQKRKsfZE&embeds_referring...

Anyone who is familiar with basic server management skills will have no problem self-hosting. every tool in the supabase stack[0] is a docker image and works in isolation. If you just want to use this Storage Engine, it's on docker-hub (supabase/storage-api). Example with MinIO: https://github.com/supabase/storage/blob/master/docker-compo...

[0] architecture: https://supabase.com/docs/guides/getting-started/architectur...

in case it's not clear why this is required, some of the things the storage engine handles are:

image transformations, caching, automatic cache-busting, multiple protocols, metadata management, postgres compatibility, multipart uploads, compatibility across storage backends, etc

>like you read my mind

we receive a lot of community feedback and ultimately there are only a few "primitives" developers need to solve 90% of their problems

I think we're inching closer to the complete set of primitives which can be used to combine into second-order primitives (eg: queues/search/maps can all be "wrappers" around the primitives we already provide)

It's more of a "accessibility layer" on top of S3 or any other s3-compatible backend (which means that it also works with MinIO out-of-the-box [0])

I don't think we'll ever build the underlying storage layer. I'm a big fan of what the Tigris[1] team have built if you're looking for other good s3 alternatives

[0] https://github.com/supabase/storage/blob/master/docker-compo...

[1] Tigris: https://tigrisdata.com

(supabase team member) Firebase is an amazing tool for building fast. I want Supabase to be a "tool for everyone", but ultimately giving developers choices between various technologies is a good thing for developers. I think it's great that Flutterflow support both Firebase & Supabase.

I know Flutterflow's Firebase integration is a bit more polished so hopefully we can work closer with the FF team to make our integration more seamless