> I’d bet you’re likely to see this from a Postgres-specific provider first, like Supabase.

we deprecated this feature in our ETL tool[0]. The functionality is still in there but we can't support some of the production features we'd need for data/schema guarantees

Iceberg is still nascent - only supporting single-table transactions (at least when we tried). A lot of important CDC/transactional semantics were "a work in progress" upstream. We shifted our focus to ducklake, which stores the catalog in Postgres

[0] https://github.com/supabase/etl

Comments URL: https://news.ycombinator.com/item?id=48826294

Points: 3

# Comments: 0

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

Comments URL: https://news.ycombinator.com/item?id=48416465

Points: 9

# Comments: 0

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...

(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

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

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

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

We expect it to be production ready this year

> 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

(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

Comments URL: https://news.ycombinator.com/item?id=46910466

Points: 9

# Comments: 7

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

> 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

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

The goals:

- Generic: Works with any Iceberg REST Catalog implementation, not tied to any specific vendor

- Minimal: Thin HTTP wrapper over the official REST API, no engine-specific logic

- Type-safe: First-class TypeScript support with strongly-typed request/response models

- Fetch-based: Uses native fetch API with support for custom implementations

- Universal: Targets Node 20+ and modern browsers (ES2020)

- Catalog-only: Focused on catalog operations at this stage

Although Iceberg is becoming very popular, we were surprised that the developer tooling is so nascent. This library is our contribution back to the ecosystem. The goal is to keep it minimal and well-maintained, so that developers can manage their warehouse from any JS server.

We are using it with AWS's new "S3 Tables". If it doesn't support other REST catalogs we'd welcome contributions

Comments URL: https://news.ycombinator.com/item?id=46203840

Points: 5

# Comments: 0

https://github.com/supabase/wrappers

It is compatible with the Iceberg REST catalog and S3 Tables (AWS S3's latest offering). Currently it supports SELECT and INSERT operations.

You can map an entire Iceberg namespace into your Postgres database like this:

    import foreign schema "warehouse"
    from server iceberg_server 
    into "my_iceberg_warehouse";

    select * from warehouse.my_table where id = 42;

    create foreign table new_table (
      id bigint,
      name text
    )
    server iceberg_server
    options (
      table 'warehouse.new_table',
      rowid_column 'id',
      create_table_if_not_exists 'true'
    );

Comments URL: https://news.ycombinator.com/item?id=46057877

Points: 1

# Comments: 1