gbartolini

7 ms·

1.
by gbartolini 5mo ago
See for example: https://infohub.delltechnologies.com/en-us/t/edb-postgres-ai...
2.
by gbartolini 5mo ago
It all depends on the storage underneath. If you have got good storage, with CNPG you have comparable results you get on bare metal PostgreSQL.
3.
by gbartolini 5mo ago
Barman Cloud was a convenient choice for CloudNativePG (CNPG) because it was developed by the same team that created Barman originally (I am part of both teams). When we started CNPG, we never anticipated it would become so popular, which h
4.
by gbartolini 2y ago
As a founder and maintainer of CNPG, it is exciting to see it used here. I would love to know more! Thanks.
5.
Making the world my single point of failure with PostgreSQL(gabrielebartolini.it)
3 points by gbartolini 2y ago|0 comments
6.
by gbartolini 3y ago
I don’t agree here. There are operators like the one I’m a maintainer of (CloudnativePG) which works directly with Kubernetes, teaching it how to handle Postgres clusters as a coordinated set of instances. Enormous improvements have been do
7.
Postgres Disaster Recovery with Kubernetes Volume Snapshots Using CloudNativePG(enterprisedb.com)
7 points by gbartolini 3y ago|0 comments
8.
by gbartolini 3y ago
I actually do not understand the point here. And maybe you are not very familiar with the concept of transactions. Backups can only account for committed transactions. However, we are talking about Postgres, here, not a generic database. Po
9.
by gbartolini 3y ago
I'm the author of this blog article in which I try to recap why running Postgres in Kubernetes is a good thing: https://cloudnativenow.com/kubecon-cnc-eu-2022/why-run-postg...
10.
by gbartolini 3y ago
The reason could be the last 4 years of evolution in Kubernetes. Have you heard of DoK Community (Data on Kubernetes)? Might be a good place where to start.
11.
by gbartolini 3y ago
Why not dedicate some worker nodes using taints/tolerations/labels, even on bare metal, with locally attached storage? I wrote this many years ago now but that's the reason why we started CloudNativePG (OpenEBS might not be t
12.
by gbartolini 3y ago
If you are interested, I suggest this article I wrote that covers the current state of major upgrades with CloudNativePG: https://www.enterprisedb.com/blog/current-state-major-postgr...
13.
by gbartolini 4y ago
I agree with your view point and concerns. That is why we took the approach to reduce the number of components and integrate everything in Kubernetes, especially with logging (we directly log in JSON to standard output) and the usage of app
14.
by gbartolini 4y ago
Maintainer of CloudNativePG here. Back then, we evaluated Crunchy Operator's source code. Being primarily imperative and using an external tool for failover, where the two main reasons we decided to start a new project in 2019 which wa
15.
by gbartolini 4y ago
Thank you!
16.
by gbartolini 4y ago
Can you please elaborate about obfuscation? Regarding being opinionated I believe that it is what we expect from an operator. An operator simulates what human DBAs in this case would do. I am a maintainer of CloudNativePG, and I have been r
17.
by gbartolini 4y ago
As maintainer of the project, I suggest looking at CloudNativePG, which is production ready (cloudnative-pg.io).
18.
by gbartolini 4y ago
One clarification about CloudNativePG. It is not EDB's anymore (or EnterpriseDB if you prefer). EDB is the original creator. The software is now entirely owned by a vendor neutral community, openly governed. We have applied for the CNC
19.
by gbartolini 4y ago
CloudNativePG Maintainer and VP of CloudNative at EDB here. We decided to go even further with the CloudNativePG operator. EDB as original creator has decided to donate the intellectual property of the source code to the community, open sou
20.
by gbartolini 4y ago
That's another good example of why CNCF is important, as in that ecosystem live technologies that are becoming standard for everything related to infrastructure, including monitoring and alerting. Prometheus is an example, Open Telemet
21.
by gbartolini 4y ago
Got it. That's an interesting point of view. I think it makes sense in the data workloads, especially in the database one. Consider for example how database workloads are still lagging behind in Kubernetes, and - most importantly - vic
22.
by gbartolini 4y ago
Can you please elaborate on this: "Could this reasoning be extended to other databases and stateful applications?"?
23.
by gbartolini 4y ago
There's definitely commonalities between operators for databases, not only with the same engine, but also different ones and similar primary/standby architecture. I agree this is something we could somehow work together as a stand
24.
by gbartolini 4y ago
The project has just been submitted to the CNCF Sandbox, it hasn't yet been accepted. There's a lot of road to be done. If we get accepted, we'll be honoured to adapt and contribute to the project until incubation. However, w
25.
by gbartolini 4y ago
Disclaimer - I'm one of the maintainers of the project Thanks for sharing the news! The project is hosted on github.com/cloudnative-pg/cloudnative-pg and it is distributed under Apache License 2.0. It manages PostgreSQL prima
26.
by gbartolini 10y ago
Some food for thought. These are the first cases that came to my mind: 1) Zero data loss backups (as far as I know, Barman is the first backup tool for PostgreSQL to implement it) 2) Monitoring ('check' command) 3) Hybrid WAL ship
27.
Streaming and “zero data loss” backups for PostgreSQL with Barman 2.0
16 points by gbartolini 10y ago|0 comments
28.
by gbartolini 14y ago
You are right. I confirm, currently it is only WAL compression (documentation is up to date). I hope that we can add one between incremental backups and retention policies in version 1.1. Which are part of the most wanted features still. :)
29.
by gbartolini 14y ago
As core team member of Barman (and manager), I want to start answering from the bottom of your request. I actually thank you for giving me the chance to answer to this question and to talk about Barman in general. 2ndQuadrant has adopted th