kiwicopple

12 ngày trướcdiscuss

(supabase employee)

confirming that we're still working hard on this. aiming to be production-ready this year. benchmarks and compatibility testing are on track

kiwicopple

tháng trướcdiscuss

Yes that’s how it will work. The transition will be seamless

kiwicopple

tháng trướcdiscuss

Hey HN, Supabase CEO

The main highlight here is that we have released Multigres v0.1:

https://supabase.com/blog/multigres-v0-1-alpha

This is open source and self-hostable. It’s not production ready yet. That will take a few more months

You can find instructions for running the operator in EKS here

https://github.com/multigres/multigres/blob/43db3a4873922eee...

kiwicopple

2 tháng trướcdiscuss

> Supabase is another one that was cool, but now it is in the AI abyss.

(supabase ceo) I'm curious what gives you this impression? it's true that a lot of platforms build on top of Supabase, but our focus is still just building the best Postgres platform we can (OrioleDB, Multigres, etc)

admittedly we've also had to shift a lot of our tooling to things like Claude/Codex, but that's more reflective of how people are building now

kiwicopple

2 tháng trướcdiscuss

> It's infamously hard to exhaustively unit-test concurrency.

a useful example from last week where TLA+ found a bug in pg_rewind:

https://multigres.com/blog/2026/05/04/tla-pg-rewind

kiwicopple

2 tháng trướcdiscuss

Oriole is under very heavy development since we acquired them. We cut a release just 2 weeks ago:

https://github.com/orioledb/orioledb/releases/tag/beta15

We expect it to be production ready this year

kiwicopple

2 tháng trướcdiscuss

clarifying a few misconceptions:

> RLS policies are executed per row

not necessarily. the planner integrates the policy expression into the query plan. stable/immutable expressions and indexable predicates aren't naively re-evaluated per row

> If SET LOCAL is omitted, current_setting() returns an empty string or throws an error depending on how your policy is written

if you're using tools like PostgREST, they set the GUC automatically per request

> RLS policies themselves are stored in pg_policies inside your database, not in your source code

Policies are plain DDL and are tracked by every serious migration tool. Off the top of my head, these tools track Policies: Sqitch, Flyway, Alembic, Atlas, Prisma migrate, dbmate

> Most migration tools do not include SQL functions

same as above

kiwicopple

5 tháng trướcdiscuss

> Why is there no InnoDB for PostgreSQL?

(we maintain OrioleDB) Mostly because the TAM API isn't mature enough yet. Hopefully we can upstream more patches so that it's possible

> undo-based MVCC storage engine project stall?

From what I could gather, it ran out of steam simply because of the difficulty of the task. There is a lot of work involved to get the requisite patches into core and the community are (correctly) cautious

kiwicopple

5 tháng trướcdiscuss

[Supabase CEO]

I’m sure there could be questions, given the brevity of this blog post. I’m happy to answer anything specific

I’ve been chatting to Dennis for a long time now and our product-ideas were very aligned. We will share more about this project in a few ShowHN’s over the coming months

kiwicopple

6 tháng trướcdiscuss

(Supabase CEO)

> The danger is when apps expose the service_role key (or the new sb_secret_... format)

Fwiw, the new secret keys are automatically revoked if they are pushed to github, and github is progressively rolling out push protection - to prevent them getting pushed in the first place. Of course, not everyone uses github

People disabling RLS, or making RLS a simple pass-through, is a battle we are constantly fighting. We have made good strides here over the past 12 months:

https://supabase.com/blog/supabase-security-2025-retro

- event triggers to enforce RLS on all tables

- lints to scan for insecure rules

- ai to write secure policies (if they are too lazy or confused to do it themselves)

- big red labels when a table is exposed

- weekly emails with security alerts

- dashboard alerts and security advisors

- contractually requiring Vibe coding platforms to expose our Security Advisors if they are integrating with us

- red teaming customers that have egregious issues (this has been surprisingly effective, just harder to scale up)

I appreciate you creating this tool - as you can see we are also “tooling up” as much as we can. If there are any other things that you think we are missing let me know and we will prioritize it

We will be introducing new AuthZ patterns this year so I’m hoping that will also help

kiwicopple

7 tháng trướcdiscuss

(Note: we work closely with the clickhouse team so this is not to intended to detract from their launch, simply to point out maintained options.)

Our CH wrapper is actively maintained, with push down, parameterized views, and async streaming: https://supabase.github.io/wrappers/catalog/clickhouse/

We see a lot of companies choosing CH with PG - it’s fantastic

kiwicopple

8 tháng trướcdiscuss

GitHub repo is here if you want to use this for self-hosted Postgres databases:

https://github.com/supabase/wrappers

kiwicopple

8 tháng trướcdiscuss

> get more Supabase Realtime back into the game if the price was more viable too

feel free to reach out to me on twitter (same username) to discuss this if you want. we are starting to think of realtime in the context of gaming so if you have feedback it would help us shape the pricing

kiwicopple

8 tháng trướcdiscuss

impressive work jmo - thanks for open sourcing this (and OSI-compliant)

we are working on a challenge which is somewhat like a homomorphic encryption problem - I'm wondering if OpenPCC could help in some way? :

When developing websites/apps, developers generally use logs to debug production issues. However with wearables, logs can be privacy issue: imagine some AR glasses logging visual data (like someone's face). Would OpenPCC help to extract/clean/anonymize this sort of data for developers to help with their debugging?

kiwicopple

8 tháng trướcdiscuss

this is the last of a 9-part series on database consensus algorithms (like Paxos and Raft):

> Raft improved accessibility but remains a monolithic algorithm that's risky to modify. This has effectively limited our flexibility in adapting consensus systems to modern cloud architectures.

The series begins here: https://multigres.com/blog/generalized-consensus

kiwicopple

9 tháng trướcdiscuss

let me follow up with the team to find out what happened here

kiwicopple

9 tháng trướcdiscuss

hey DANmode - supabase ceo here. similar to the sibling thread I want to make sure I know what happened here:

  1. someone created an website using supabase with email logins (and possibly edited the template / opt-out link)
  2. someone signed you up to that service - you received an email from that app 
  3. you sent us an email (to [email protected] or similar) to report abuse
  4. we emailed a few months later with the generic email you posted

First, I'm sorry you had a bad experience. we have been historically very on-top of our support emails, but this year the tickets have grown ~10x while our team can only grow ~2x. We have had to make short-term trade-offs (automations) which are sub-par so that we can catch up with the growth and primarily focus on the paying customers

I'm be the first to acknowledge that this is something we want to improve. Unfortunately that will take time and iterations - you are experiencing our support (i hope) at it's worst. We sent an email to the backlog of unanswered free-plan emails just to acknowledge and redirect them somewhere we can offer more support

For security/fraud, we have a slightly different process: https://supabase.com/.well-known/security.txt

This process is to ensure that we _don't_ miss emails, like we did with yours.

You post here is helpful for us to figure out the areas that we need to improve. Again, I'm sorry that we didn't give you a good impression the first time - all we can do is iterate based on feedback like yours. If you want to share more my email is in my profile

kiwicopple

9 tháng trướcdiscuss

thanks for the tag lucasknight - i'll respond inline to OP about their email situation

> your current AWS situation

I think the assessment here is accurate:

https://x.com/theo/status/1979271205279666586

> Looked into this a bit. I don’t think “downtime” is a fair way to report on this. No existing databases are affected. Amazon is literally out of boxes in eu-west-2, so Supabase can’t provision NEW DBs in that one specific region

I want to own the fact that we can be multi-cloud, and that we can work with AWS on their capacity planning (note: this is not a typical request for an increase on a soft limit). We are working through both of these options. That said, the Reddit poster classifying this as days of downtime is not entirely fair, and it makes it harder to for us to over communicate with our community. Throughout this period we had days where there was free of capacity on AWS and we chose to leave the status up until we have finalized our conversations with AWS.

I also want to acknowledge that there is a broader AWS issue today in us-east-1 which affects us (and most other companies today) that is unrelated

https://news.ycombinator.com/item?id=45640838

kiwicopple

10 tháng trướcdiscuss

fwiw, we have a team working on OrioleDB at supabase, with the plan to get to GA later this year or early next year. we'll continue to submit patches upstream for the TAM, and of course that will take as long as it takes for the community to accept them. Our focus right now reliability and compatibility, so that the community can gain confidence in the implementation

kiwicopple

10 tháng trướcdiscuss

An alternative viewpoint which we are pretty open about in our docs:

> our technological choices are quite different; everything we use is open source; and wherever possible, we use and support existing tools rather than developing from scratch.

I understand that people get frustrated when there is any commercial interest associated to open source. But someone needs to fund open source efforts and we’re doing our best here. Some (perhaps non-obvious) examples

* we employ the maintainers of PostgREST, contributing directly to the project - not some private fork

* we employ maintainers of Postgres, contributing patches directly

* we have purchased and open sourced private companies, like OrioleDB, open sourced the code and made the patents freely available to everyone

* we picked up unmaintained tools and maintained them at our own cost, like the Auth server, which we upstreamed until the previous owner/company stopped accepting contributions

* we worked with open source tools/standards like TUS to contribute missing functionality like Postgres support and advisory locks

* we have sponsored adjacent open source initiatives like adding types to Elixir

* we have given equity to framework creators, which I’m certain will be the largest donation that these creators have (and will) ever receive for their open source work

* and yes, we employ the maintainers of Vitess to create a similar offering for the Postgres ecosystem under the same Apache2 license

kiwicopple

Submissions

Multigres Supports Listen/Notify Across Pooled Connections

Are Memories Transferable – Or Edible?

A 2.5x faster Postgres parser with Claude Code

Show HN: Iceberg-JS, a TypeScript Client for the Apache Iceberg REST Catalog

Show HN: Apache Iceberg FDW for Postgres

Open Data Standards: Postgres, OTel, and Iceberg

Generalized Consensus: Consistent Reads

comments