728x90

오픈소스 DBMS / 인프라 오늘의 핵심 흐름

아래 내용은 최근 24시간 내 수집된 원문 보도를 바탕으로 정리한 핵심 이슈입니다. 확정되지 않은 사실은 추가하지 않고, 원문에서 확인되는 범위 안에서 의미를 설명합니다.

 

1. Jan Wieremjewicz: Why PostgreSQL needs an AI usage policy

We often hear that open source is about people. People who contribute their time and, in a way, parts of their lives to work on software that is available for everyone without limitations and without licensing costs. The more popular a project becomes, the more often we also hear about the need for sustainable open source. Nothing surprising here. Often projects start off as “scratching ones itch” and it’s very appreciated when others notice the work done. The more time passes and the more the work becomes appreciated, the higher the chances that there will be a need to spend more time on the project.

왜 중요한가: Planet PostgreSQL의 보도는 이 이슈가 단일 사건에 그치지 않고, 오픈소스 DBMS / 인프라의 기술 도입, 비용 구조, 운영 우선순위에 영향을 줄 수 있음을 보여줍니다. 보도에 나온 사실과 아직 확인되지 않은 전망을 구분해 해석하는 것이 중요합니다.

확인할 포인트: 후속 발표에서 실제 적용 범위, 일정, 비용 변화, 규제 또는 공급망 영향이 구체화되는지 살펴봐야 합니다. 같은 주제를 다루는 다른 원문과 비교하면 일시적 이슈인지 구조적 변화인지 판단하는 데 도움이 됩니다.

실무 관점: 관련 조직은 즉시 결론을 내리기보다 현재 시스템과 정책, 예산, 운영 절차에 어떤 연결점이 있는지 점검하는 것이 좋습니다. 원문에 없는 수치나 계획을 확정 사실처럼 받아들이지 않고, 후속 보도와 공식 자료를 함께 확인해야 합니다.

 

2. Shaun Thomas: Looking Forward to Postgres 19: Split Personality

Postgres has had native support for declarative partitions since version 10, and every release since has filed off another rough edge. We got partition-wise joins, default partitions, hash partitioning, and the ability to attach and detach partitions concurrently. By any reasonable measure, declarative partitioning is one of the great success stories of modern Postgres.Despite the power here, it's always been a kind of one-way ratchet. Creating or dropping partitions was easy. But reorganizing existing ones was a different beast entirely. There's no syntax or tool to assist in the event we want to convert a table to a partition set, or revise an existing design. Instead, it's just a long series of manual statements to carve the table up into partitions, or perhaps leveraging pg_partman to do it instead.Well, Postgres 19 finally has an answer to that. Let's talk about the current state of the art, and how the new and syntax for ALTER TABLE may change the story. The Way Things Were Suppose we have a busy partition and want to break it into smaller pieces. The current procedure works something like this: Create new partitions as standalone tables. Copy the relevant rows into each one. Detach the old partition. Attach the new ones. Drop the empty table husk. It's serviceable, but also tedious, error-prone, and subject to various locks that can delay the process. Postgres 19 collapses that whole routine into one statement.Before diving into how, let's create something realistic to play with. How about an analytics pipeline containing a stream of events partitioned by time? The initial state will be one partition per quarter for 2026:Now let's inject a single event into every day of the year so each partition has something to hold:Let's assume that a quarter felt reasonable when we drew it up, but traffic in Q1 turned out to be heavier than expected. Now, querying three months of data to find a single morning's worth of clicks is wasteful. We'd much rather have monthly partitions there. In the past, that meant the migration shuffle. Be Fruitful and Multiply The new syntax reads almost exactly like what we might say out loud. "Take this partition, and split it into these smaller ones":That's it. The original partition is gone, replaced by three monthly children, and Postgres moved every row into the partition where it now belongs. Let's verify that:No temporary table -> copy -> detach dance. Instead, the rows land exactly where the new bounds dictate. Seventeen days of January data, a full February, and a full March. The whole operation is transactional too, so it's perfectly valid to abort in the middle and leave the original structure unchanged.One detail worth noting: the new partitions must cover the entire range of the partition being split, with no gaps or overlaps. Postgres will point out mistakes here:That's a good error; it tells us precisely what's wrong and exactly how to fix it. E Pluribus Unum Splitting is only half the story. The reciprocal scenario is just as valid. We could just as easily have a pile of old partitions that nobody queries individually anymore and want to de-clutter. When 2026 is well behind us, three monthly partitions for Q1 become pure overhead.Let's fold them back into a single quarter:The three monthly partitions collapse into one, and all 76 rows come along for the ride:Notice that we reused the name for the result. That's allowed, because the partitions feeding the merge are consumed in the process. The same trick works with , which is genuinely handy when carving up a default partition, as we'll see in a moment.Merging carries the same adjacency rule as splitting. The partitions being combined must sit next to each other on the number line with no gaps between them. Try to merge two partitions with a third wedged in the middle, and Postgres refuses: On Distributing Defaults Here's where these commands earn their keep in the real world. Imagine a table where data sometimes arrives for time ranges we have yet to allocate. That's what the default partition is for: a catch-all that scoops up anything unclaimed by existing partitions.Those two May and June rows had nowhere else to go, so they fell into : In the past, promoting that stray data into a proper Q2 partition was something of a pain. We couldn't simply attach a new partition that overlapped the default while it held matching rows. Consider:Now we don't have to worry about that:The May and June rows migrated into the brand new partition, and the default partition remains no worse for the wear. That alone is worth the price of admission. Lost in Translation But like any Ikea furniture, sometimes we lose a few pieces during assembly. Postgres drops any objects defined directly on the partitions during a split or merge procedure. Consider this scenario where we have a partition-local index on January and a constraint on February.This is what happens during a merge:Both the constraint and index are gone without a trace. Thankfully there's an important distinction between objects defined on the parent and objects defined on an individual partition.An index created on the parent table itself is a partitioned index, and Postgres maintains a copy on every partition automatically. When a merge or split produces a new partition, that partition gets its copy of the parent index just like any freshly attached partition would. Watch what happens when we add a parent index alongside a partition-local one, then merge:The merged partition comes back carrying the parent's indexes and nothing else:The parent index survives, recreated automatically under a generated name. The local does not. So we could look at it like this: anything inherited from the parent is rebuilt, and anything attached to a single partition is forfeit. If partitions carry their own bespoke indexes, constraints, or triggers, take note of these if any need to be recreated following a merge. An Exclusive Club The other major caveat is about contention. There is no variant of these commands yet. Both and take an lock, and they hold it for the entire duration of the operation.How heavy is that lock, exactly? Let's see:Look at the top row. The lock isn't just on the partition being split. It's on the parent table itself. For as long as the operation runs, the entire partitioned table is frozen. All reads and writes will wait until the completes. That's more than a little inconvenient.That's only a few milliseconds for a small partition, and nobody notices. Partitions containing hundreds of millions of rows could be locked for minutes or even hours during a split or merge. So treat these commands like any other statement: dangerous at peak traffic. Until a concurrent variant arrives, the heavy lock is the price of admission. Hash Need Not Apply Native table partitions in Postgres have come a long way, but the merge and split functionality are still early in their evolution. As a result, some omissions remain, such as hash-based partitions.Splitting and merging both work on and partitioned tables, but a hash-partitioned table will balk immediately:Perhaps this might come in the future, or perhaps not. How does one "merge" a hash, exactly? We'd have to change the base modulus, thereby affecting all child partitions rather than a distinct subset. Still, it pays to be informed. Final Thoughts The journey of 1000 miles begins with a single step. Declarative Postgres partitioning took that step way back in version 10, and now it continues the pilgrimage by adopting and syntax. Due to their relative youth, they're missing some creature comforts such as concurrent operation. That's no small omission, especially given the access exclusive lock they incur.But the foundation is there. If the history of Postgres partitioning tells us anything, the rough edges will be smoothed off release by release. A concurrent variant feels almost inevitable. Until then, maintenance windows are the only option when splitting or merging partitions. If availability is of utmost importance, the old table-swap polka is still an option.So pull down a Postgres 19 build and experiment a bit with the new and functionality. It's something a lot of users have requested, and now it's finally here!

왜 중요한가: Planet PostgreSQL의 보도는 이 이슈가 단일 사건에 그치지 않고, 오픈소스 DBMS / 인프라의 기술 도입, 비용 구조, 운영 우선순위에 영향을 줄 수 있음을 보여줍니다. 보도에 나온 사실과 아직 확인되지 않은 전망을 구분해 해석하는 것이 중요합니다.

확인할 포인트: 후속 발표에서 실제 적용 범위, 일정, 비용 변화, 규제 또는 공급망 영향이 구체화되는지 살펴봐야 합니다. 같은 주제를 다루는 다른 원문과 비교하면 일시적 이슈인지 구조적 변화인지 판단하는 데 도움이 됩니다.

실무 관점: 관련 조직은 즉시 결론을 내리기보다 현재 시스템과 정책, 예산, 운영 절차에 어떤 연결점이 있는지 점검하는 것이 좋습니다. 원문에 없는 수치나 계획을 확정 사실처럼 받아들이지 않고, 후속 보도와 공식 자료를 함께 확인해야 합니다.

 

3. Security Profiles Operator v1: Stable APIs, Security Hardened, and Shaping Upstream Kubernetes

Linux provides powerful kernel-level security mechanisms, seccomp, SELinux, and AppArmor, that restrict what containerized workloads can do. Each uses profiles that define permitted behavior, but writing, distributing, and maintaining those profiles by hand is tedious and...

왜 중요한가: CNCF Blog의 보도는 이 이슈가 단일 사건에 그치지 않고, 오픈소스 DBMS / 인프라의 기술 도입, 비용 구조, 운영 우선순위에 영향을 줄 수 있음을 보여줍니다. 보도에 나온 사실과 아직 확인되지 않은 전망을 구분해 해석하는 것이 중요합니다.

확인할 포인트: 후속 발표에서 실제 적용 범위, 일정, 비용 변화, 규제 또는 공급망 영향이 구체화되는지 살펴봐야 합니다. 같은 주제를 다루는 다른 원문과 비교하면 일시적 이슈인지 구조적 변화인지 판단하는 데 도움이 됩니다.

실무 관점: 관련 조직은 즉시 결론을 내리기보다 현재 시스템과 정책, 예산, 운영 절차에 어떤 연결점이 있는지 점검하는 것이 좋습니다. 원문에 없는 수치나 계획을 확정 사실처럼 받아들이지 않고, 후속 보도와 공식 자료를 함께 확인해야 합니다.

 

4. MariaDB Privacy-First Stack: Nextcloud, Passbolt and MariaDB Server

I hear this sentence a lot: “We care about privacy.” Good. But then you look a bit closer. Files are on some cloud platform. Nobody is completely sure which settings were changed two years ago. … Continue reading \"MariaDB Privacy-First Stack: Nextcloud, Passbolt and MariaDB Server\" The post MariaDB Privacy-First Stack: Nextcloud, Passbolt and MariaDB Server appeared first on MariaDB.org .

왜 중요한가: MariaDB Blog의 보도는 이 이슈가 단일 사건에 그치지 않고, 오픈소스 DBMS / 인프라의 기술 도입, 비용 구조, 운영 우선순위에 영향을 줄 수 있음을 보여줍니다. 보도에 나온 사실과 아직 확인되지 않은 전망을 구분해 해석하는 것이 중요합니다.

확인할 포인트: 후속 발표에서 실제 적용 범위, 일정, 비용 변화, 규제 또는 공급망 영향이 구체화되는지 살펴봐야 합니다. 같은 주제를 다루는 다른 원문과 비교하면 일시적 이슈인지 구조적 변화인지 판단하는 데 도움이 됩니다.

실무 관점: 관련 조직은 즉시 결론을 내리기보다 현재 시스템과 정책, 예산, 운영 절차에 어떤 연결점이 있는지 점검하는 것이 좋습니다. 원문에 없는 수치나 계획을 확정 사실처럼 받아들이지 않고, 후속 보도와 공식 자료를 함께 확인해야 합니다.

 

정리와 시사점

개별 뉴스는 단독으로 보기보다 기술, 정책, 수요, 비용 구조의 변화와 함께 읽어야 합니다. 아래 원문 출처를 통해 세부 사실과 후속 보도를 확인할 수 있습니다. 특히 기사 제목만으로 의사결정을 내리기보다 보도 본문의 적용 범위와 발표 주체, 시점, 전제 조건을 함께 검토해야 합니다.

 

 

음성 브리핑으로 듣기

글 내용을 음성 브리핑 영상으로도 정리했습니다. 이동 중이거나 화면을 오래 보기 어려울 때 아래 영상으로 핵심 흐름을 먼저 확인할 수 있습니다.

유튜브에서 음성 브리핑 듣기

 

 

원문 출처 및 참고 자료

이 글은 아래 원문 자료를 바탕으로 작성되었습니다.

728x90
반응형
저작자표시 비영리 변경금지 (새창열림)

+ Recent posts

티스토리툴바