ahachete

Thank you for your feedback. I'm trying to extract possible improvement actions from your comment, and here are my thoughts.

That certificate expiry issue was unfortunate, but was resolved (if I'm not mistaken) a couple of years ago.

StackGres is just a control plane, your database is as stable as a standalone one. StackGres itself may fail and it won't affect your database, it's not on the data plane. Indeed, it has a feature to "pause it" if you need to perform some manual operations (otherwise everything is automated).

There are procedures to reconstruct a database from PVC. It's arguably tedious, but should be much simpler than running a Postgres pod without the help of an operator like StackGres.

As for the ratio of issues: most of the issues that we get are feature and/or extensions requests, and certainly we can't tackle them all. Most, if not all, outstanding issues are addressed within a reasonable time frame. Is there any particular issue that would itch you that is open? I'd be happy to personally review it. Yet, there are as of today more than 2K closed issues, I won't call that a small number.

I'd also weight the importance of issues, like the split brain that CNPG suffers [1] and that apparently won't even be solved. StackGres relies instead on the trusted and reputed Patroni, which is known NOT to risk split brains that could lead to severe data loss.

[1]: https://github.com/cloudnative-pg/cloudnative-pg/discussions...

Hi, StackGres founder here.

We're constantly striving to improve the user experience and the quality of StackGres. Would you mind sharing some feedback as to what made your experience not good with it?

Did you join the Slack Community (https://slack.stackgres.io/) to ask if you were facing some trouble? It always helps, even if it is just by sharing your troubles.

(If you'd like to share feedback and do so privately, please DM on the Slack Community)

Your feedback will be much appreciated.

Hi, StackGres founder here.

We're constantly striving to improve the user experience and the quality of StackGres. Would you mind sharing some feedback as to what made your experience not good with it?

Did you join the Slack Community (https://slack.stackgres.io/) to ask if you were facing some trouble? It always helps, even if it is just by sharing your troubles.

(If you'd like to share feedback and do so privately, please DM on the Slack Community)

Your feedback will be much appreciated.

[edit]: typo

Does the unused index feature look into replicas? (I guess it doesn't) It's risky to delete an unused index by looking at a single instance, since it may be used by other read replicas.

Using natural keys is what actually can prevent duplicate rows. In your above example, if email is the PK, there would be no duplicates. But adding an id as a PK would essentially keep your database with duplicates:

(1, 'bob', 'bob@bobco.com')

(2, 'bob', 'bob@bobco.com')

Logical replication does NOT require a primary key. It requires either a primary key, a unique index or to define a replica identity.

Sure, that still boils down, in most cases, to having a PK (replica identity is normally not a good idea), but there are cases where this would not be the case.

If I'm not mistaken, since 25.04 root-on-ZFS is available (as experimental) in the installer.

I still prefer to do root on ext4 and then a proper ZFS pool for all the mountpoints I want, where I can configure as I wish with encryption and compression. Primary reason is that I don't keep sensitive data on root, but I want a bootable system whatever happens. And this use case is perfectly supported, so it's more than enough for me.

> and technically you can also use ZFS on Linux, even if it's painful

Maybe on some distros, but on Ubuntu is just an `apt-get install` away, or can be even be added from installation time. I've been using it for many years without any issues and the experience is great.

I actually combine some non-ZFS filesystems with ZFS with encryption and compression for all my setups, including my laptop. I plan to blog shortly about it and how I'm automating it all. Target is also a Framework laptop, too.

This is conceptually similar to what we did for Postgres extensions at the StackGres [1] project. I gave a talk at a Kubecon about it [2].

However, this scheme is not perfect. Some Kubernetes security solutions enforce immutable containers, and once the agent pulls any additional file into the container, it will be flagged. It's also harder to reason about the security of the image (think CVEs, etc), given that its true contents are not known ahead of time.

We have also worked on a solution for this, which is to create dynamic container images. It still requires (as of today, may change in the future) restarting the container, but it keeps container images immutable. Apologies for the self plug, but I believe it may be interesting that I'll speak about it in the Container Days conference in September [3].

[1]: https://stackgres.io

[2]: https://aht.es/#talks-postgres_extensions_in_kubernetes

[3]: https://www.containerdays.io/containerdays-conference-2025/a...

(edit: formatting)

For inserts is "easy" if there's no possibility to write the same PK value twice (e.g. PK are random values like uuids or include as part of a natural key a identifier from the writer that's unique -shard id, region id, you name it-).

Once you have done that, for updates and deletes you need to keep the same rule (i.e. don't update "foreign" rows).

If you do this, no other technique is needed. Partitions, however, are potentially a good technique to enforce some of these invariants, which gives us quick understanding of where data is originating from given the table name. Same could apply to schemas.

RLS may also help enforce these invariants.

I'm not tired of reminding everyone that "conflict resolution" is no more than an euphemism for "breaking durability by dropping already committed and acknowledged data".

Either architect for no data overlap on writes across all the "actives" (in which case software like pgactive could be a good deal) or use a purely distributed database (like Yugabyte).

I think that there's enough evidence that AZs are kms apart.

> And here for AWS multi-AZ losing data: https://news.ycombinator.com/item?id=4115937

That link is from 2012, 13 years ago.

AFAIK as of today AWS provides strong guarantees about the AZs being physically, network, and power isolated of each other.

> Most notably, 'null'::jsonb = 'null'::jsonb is true whereas NULL = NULL is NULL

Because 'null' in the JSON spec is a literal value (a constant), not SQL's NULL. Nothing to see here.

https://datatracker.ietf.org/doc/html/rfc7159

Last time I checked, Firecracker didn't have a very compelling I/O story, which made it in my opinion not completely adequate for running Postgres (or any other database).

In contrast, other similar VMM seem to have a better one, like Cloud Hypervisor [1]. Why then FC and not CH? (I've nothing against FC, actually love it and have been using it, but it appears not being the best I/O wise).

[1]: https://github.com/cloud-hypervisor/cloud-hypervisor

I was thinking of a similar approach, but mounting /nix/store from the host into the guest will only work if you have a single guest.

For multiple guests, you should rely instead on: * A snapshot-able filesystem with the option to create clones (like ZFS). I think this is a great idea actually. * Exporting /nix/store via NFS, so you can have multiple writers (but this creates some tight coupling in that accidentally deleting stuff there may disrupt all guests).

AGPL is fully open source, and definitely allows you to host it without open sourcing anything of your code. That's one of the very freedoms that the open source definition contains.

Lenovo and Dell have some laptops with Linux, and they are very good ones.

(not sure if you meant rugged ones, that may not be the case, but I guess this is a tiny percentage of the market)

Interested in contributing/co-writing such a runbook for StackGres? [1]

[1]: https://stackgres.io/doc/latest/runbooks/

AGPL is the best OSS license to ensure project continuity as Open Source. That simple.

Permissive licenses allow for proprietary forks, which may become more successful than the upstream project.

AGPL would be able to benefit from any improvements from any fork, and all those will remain OSS for everyone.

Nothing written here is related in any way to monetization.

Congratulations!

I also love writing AWS API-compatible services. That's why I did Dyna53 [1] ;P

(I know, unrelated, but hopefully funny)

[1] https://dyna53.io

I'm very happy to hear that StackGres is helping you out. Your feedback is greatly appreciated :)

> The things I mentioned (local symbol auto-complete, reference-chasing, global go-to-symbol) are things that modern code editors do by default for any programming language

Sure, they can. But as said, they are still quite basic stuff compared to what IDEs do. It's better than nothing, but they don't contribute to productivity as IDEs do.

> Honestly, I think I just... haven't ever felt the need to do these things in Java?

This is surprising for me, but hey, each of us are a different use case.

My recommendation is to try an IDE extensively, and then you decide what suits you better. I did this, and never looked back (for Java programming; I'm still using Vim extensively for general text edition, for example).

My experience is that you are slower/way slower without an IDE.

I'm myself a CLI person, and I'd consider myself quite proficient using the shell and console editors like Vim. I know many shortcuts and I manage myself quite well and very fast there.

However, when I do Java development I use an IDE. There's so many things that an IDE does that regular text editors don't (sure, there's ways to hack them to do some subset of those things, but that takes a lot of setup time and they'll always be a subset). Programming efficiency is not about typing fast or speeding up moving a paragraph of code to the end of the file by doing d-}-G-p; but rather to ask the IDE to do a refactor of some code, remove unused dependencies, click on a method to see it's definition or get contextual JavaDoc, to name a few (basic) features that IDE give you,

I applaud the decision to use AGPL-3.0.

For me, it's a license that provides forward guarantees to the Community: no proprietary forks can happen, so any fork will be an OSS fork from which the upstream project may benefit too, which benefits all users.

That's the reason we chose this license for StackGres [1], another project in the Postgres space.

[1]: https://stackgres.io

The (internal) use of DataFusion to create new, powerful extensions for Postgres is a very clever idea. Very good work for the ParadeDB team.

I like this one very much. Very simple way to avoid having to use different set of tools and query languages (or more limited query languages) to query lakes.

The software seems to be licensed under the BSL license [1] which is not open source. Please correct the title to avoid misleading headlines.

[1] https://github.com/akaunting/akaunting/blob/master/LICENSE.t...

Because of the little gains and large additional effort required in exchange.

rpm/apt are quite involved to package and the tooling is (at least compared to OCI) limited. They would provide little advantage over OCI which works on any packaging system and even OS. They don't enjoy the ecosystem advantages of OCI, despite their age.

In summary, it could be doable, but it would require much more additional effort than packaging in OCI first.

But sure, since it can be done, maybe someone wants to take on it. I won't be down for the job myself ;)

Happy to see this in HN (thanks for submitting it!). OP here. AMA