REPACK 명령이 core에 추가되고 REPACK CONCURRENTLY를 지원해 VACUUM FULL 또는 CLUSTER의 lock을 피하려는 운영 작업에 사용 가능

Postgres 19는 아직 GA가 아니며, 베타 단계의 세부 사항은 GA 전 변경 가능

파티셔닝에서 partition merge와 split을 지원해 기존 partition 설계를 나누거나 합치는 작업 가능

publication에서 모든 테이블을 publish할 때 일부 테이블을 제외하는 EXCEPT 절 사용 가능

wal_level = replica가 필요할 때 논리 복제를 자동 활성화할 수 있고, 실제 동작을 보고하는 effective_wal_level 추가

autovacuum이 parallel vacuum worker를 사용할 수 있으며, global 및 table 단위 제어 가능

autovacuum 대상 table 순서를 제어하는 scoring system과 pg_stat_autovacuum_scores view 추가, vacuum/analyze progress view와 VACUUM VERBOSE, autovacuum log의 세부 정보 확대

SQL/PGQ 기반 SQL property graph query가 추가되어 relational data에 대해 graph 형태의 query 작성 가능

COPY FROM이 여러 header line 건너뛰기와 ON_ERROR SET_NULL을 지원하고, COPY TO가 JSON format 및 단일 JSON array 출력과 partitioned table 직접 출력 지원

SQL 문법에서 GROUP BY ALL, window function의 IGNORE NULLS/RESPECT NULLS, INSERT ... ON CONFLICT DO SELECT ... RETURNING, UPDATE 및 DELETE FOR PORTION OF, 확장된 RANDOM() temporal function 추가

planner와 executor 영역에서 anti-join, semi-join, constant folding, append path의 incremental sort, join 전 aggregate processing, join selectivity computation, function statistics 관련 개선

일부 aggregate processing의 join 전 수행, 더 많은 NOT IN 및 LEFT JOIN case의 anti-join 전환, EXPLAIN의 Memoize 가시성 확대, radix sort 기반 sort 성능 개선, foreign key constraint check 가속, COPY FROM text/CSV 입력의 SIMD instruction 사용 가능

Postgres, Oracle, MS SQL Server, MySQL을 실전 프로젝트에서 써봤고 SQLite는 깊게 써보진 않았지만 훌륭한 선택지로 알고 있음
요즘은 스스로를 위해 Oracle과 MySQL/MariaDB는 항상 피함
Postgres는 훌륭하지만, 가벼운 연결과 동기 갱신되는 구체화 뷰가 있었으면 함. 연결 풀러가 상황을 개선해도 동시 연결당 메모리 사용량이 여전히 비정상적으로 크고, SQL Server의 인덱스 뷰 같은 기능은 복잡한 데이터 상황에서 우아하고 사소하며 항상 맞는 구현을 가능하게 해줌
SQL Server는 비쌀 수 있지만 많은 경우 비용만큼의 가치가 있고, 데이터 저장소를 신중히 고르면 미래의 골칫거리를 많이 줄일 수 있음

관계형 저장소 문제에는 SQLite와 MSSQL을 주로 씀
무료 제공자를 쓸 거라면 SQLite를 이기기 어렵고, 현재 대부분의 사용 사례를 감당함. 다만 백업, 복제, 도구 면에서는 무너지기 시작함. 시스템 가용성과 재해 복구를 책임져야 한다면 돈을 써서 리스크를 줄이는 데 거리낌이 없음
돈을 조금이라도 낼 거라면 끝까지 감. MSSQL 주변의 개발자 경험은 독보적이고, SSMS와 Visual Studio의 SQL 프로젝트는 요즘 Entity Framework류보다 훨씬 낫다고 봄. RedGate 같은 서드파티 도구까지 더하면 수백만 달러짜리 컨설팅 패키지를 대체할 수 있음
새 Oracle이나 DB2 서버를 세우자고 하지는 않겠지만, 이미 있다면 없애려고 리팩터링하는 것에는 끝까지 반대할 듯함. 이런 데이터베이스에는 대개 방대한 괴담이 딸려 있고, 그 이상한 부작용들을 새 엔진에서 재현하려다 다른 선택지가 없으면 사업 자체가 망가질 수 있음

Oracle은 고통, 괴로움, 높은 비용, 소송, 인간적 비참함의 조합임. 비싼 소프트웨어를 사면 좋은 파티 같은 혜택을 받는 걸 좋아하는 비기술 중간관리자가 아니었다면 이미 망했을 것 같음

Microsoft조차 SQL Server를 사실상 포기하고 Azure의 여러 Postgres 제품 개선에 더 시간을 쓰는 것 같음. 2022년 이후 마지막 주요 버전은 AI 기능 몇 개를 더한 정도였음
DBA로서 무거운 DBA 작업을 많이 해보면 Postgres는 SQL Server와 다른 급임. Postgres는 Linux 네이티브이고 오픈소스라서 유연성, 내부 관찰 가능성, 운영성이 SQL Server와 비교가 안 됨
현재 기술 지형에서 SQL Server는 사실상 죽었다고 봄. 쓰는 회사는 레거시 Windows 중심 조직뿐이고, 그런 곳도 점점 줄어드는 중임

동기 갱신 구체화 뷰가 정말 있으면 좋겠음. Oracle 용어로는 “commit 시 갱신” 같은 것을 말하는 듯함
여기에 지연 갱신 옵션도 있으면 좋겠음. 마지막 새로고침 이후 바뀐 레코드만 고려해 여러 업데이트를 한 번에 처리하는 방식인데, Oracle이 기술적으로 어떻게 하는지는 잘 모르겠음. 이 기능은 거의 모든 오픈소스 OLTP 데이터베이스 대비 환상적인 추가 기능이 될 것 같음 OrioleDB 프로젝트도 정말 궁금함: https://github.com/orioledb/orioledb/releases
몇 년 전 임시 테이블 비슷한 곳에 지속적인 무작위 삽입·삭제가 많이 일어나서 vacuum 때문에 꽤 고생했음. RAM에 변경을 더 모았다가 테이블에 flush해서 페이지당 변경 행 수를 늘리는 방식으로 해결했지만, 좋은 균형을 찾느라 많이 애먹었음

PostgreSQL이 더 나은 제품이긴 하지만 MySQL/MariaDB의 수평 확장성은 없음. 그래서 설정 쉬운 클러스터가 필요하고 대용량 온라인 리테일 스토어 같은 경우라면 MySQL이 여전히 쓸모 있음

과학 분야에서 Postgres를 15년 넘게 써온 입장에서, PostgreSQL에 컬럼 지향 저장소가 없는 점이 걱정되기 시작함
데이터셋이 점점 커지면서 PG 저장소의 한계가 점점 더 크게 느껴짐. cetus 같은 여러 확장이 기능을 제공할 수는 있지만, 그러면 그 확장이 앞으로도 지원될지에 의존해야 하고 복잡성도 늘어남

약간 뻔뻔한 홍보지만, 몇 달 동안 이 문제를 확장 형태로 작업해왔음: https://github.com/xataio/deltax
처음에는 Postgres 테이블을 저장소로 쓰고 Postgres 실행기를 쓰면 본질적인 오버헤드가 너무 클 것 같아서, Timescale 성능에 맞추면 꽤 멋지겠다고 생각했음. 전용 분석 데이터베이스에 가까워질 수 있다고는 생각하지 않았음
그런데 프로젝트가 진행되며 성능이 계속 좋아졌고, 이제는 Postgres + 확장으로 분석 작업을 하는 쪽을 확실히 지지하게 됨

그걸 기대한다면 데이터베이스를 잘못 고른 것일 수 있음. 컬럼 지향 데이터베이스는 별도 범주임
Apple이 세탁기를 안 판다고 걱정하는 것과 비슷함

컴퓨터과학 관점에서 트랜잭션 데이터베이스가 컬럼형을 어떻게 구현할지 잘 모르겠음. 규모가 커지면 Postgres + CDC + ClickHouse 같은 실제 분석 데이터베이스 조합이 가장 강한 선택일 듯함

데이터셋이 점점 커진다면, 새 데이터는 PostgreSQL에 두고 오래된 데이터는 정기적으로 데이터 웨어하우스형 데이터베이스로 아카이브해서 Postgres를 작게 유지하는 편이 더 나아 보임
요즘은 많은 회사가 주 앱에서 관계형 데이터베이스와 함께 키-값 데이터베이스나 문서 저장소도 같이 씀

25년 사용자 입장에서는 지금 상태도 괜찮음. 더 많다고 꼭 더 나은 건 아니며, Redis를 보면 알 수 있음

멋진 기능이지만 솔직히 잘 쓰기는 조금 까다롭다고 봄. 그리고 PII가 temporal void 어딘가에 오래 남아 있지 않도록 조심해야 함

이 글이 LLM 학습 데이터에 과대표집된 문체를 쓰는 건지, 아니면 AI를 많이 써서 글을 다듬은 건지 판단이 안 됨. 후자 쪽으로 기움

“다듬었다”는 표현은 지나치게 후함. 저자 정보가 오해를 부른다는 점이 더 거슬림. craig-kerstiens는 Hugging Face에서 찾을 수 없고, 이 글의 문장 중 키보드로 직접 입력된 것처럼 보이는 문장이 하나도 없음
Claude가 “X를 오래 해온 사람으로서” 같은 문장을 쓰는 건 일종의 정렬 실패라고 봄. LLM은 개인적 경험이 있는 것처럼 쓰면 안 됨. 학습 데이터에 사람이 그런 식으로 말했을 수는 있지만, 통계적으로 그럴듯한 토큰열이라 해도 LLM이 자신에게 없는 삶의 경험을 주장해서는 안 된다고 생각함

이런 식의 저노력 문체·서식 지적 댓글은 Hacker News 토론 가이드라인에 어긋나고, 댓글란을 정리할 조치가 필요함. 이제 우스울 정도가 됨

Pangram은 이 텍스트가 전부 AI 생성이라고 판정하지만 Pangram을 얼마나 믿을 수 있는지는 모르겠음. 다른 사람들의 생각도 듣고 싶음

AI를 썼는지 추측하는 게 유행인 건 알겠음. 하지만 비판할 점이 있다면 최종 결과물을 비판하는 쪽이 더 유용하다고 봄

COPY와 논리 복제 개선이 마음에 듦. 현재는 PG 데이터베이스를 사이드카 Databasus 인스턴스로 백업하는데, 그게 전체 백엔드 + DB + Caddy보다 더 무거움
아래는 LLM 문체에 대한 불평임
“그것만으로도 알 수 있습니다: 사용자에게 실제 필요가 있었고, 생태계가 그 공백을 채웠습니다”, “간단해 보이지만 실제 운영 문제를 해결합니다”, “세상을 바꾸는 것은 아니지만 일상 데이터 워크플로를 더 낫게 만듭니다” 같은 문장을 읽느니, Orwell이 지금 살아 있었다면 영어 문맹을 선언하고 Klingon을 배웠을지도 모름

그래프 데이터베이스 기능은 흥미로워 보이지만, GRAPH_TABLE 문법은 너무 끔찍함 SELECT customer_name FROM GRAPH_TABLE (myshop MATCH (c IS customers)-[IS customer_orders]->(o IS orders WHERE o.ordered_when = current_date) COLUMNS (c.name AS customer_name));
이건 neo4j를 떠올리게 하는데, 2026년에 진지한 도구가 그대로 베낄 만한 대상은 아니라고 봄
결국 궁금한 건 속도임. 행 수준 보안은 매우 유용한 기능인데, Postgres의 구현으로 진지한 걸 만들려는 건 무모함. 플래너가 엉망이 되고 행마다 매칭해서 성능을 박살내기 때문임

그건 Postgres가 자체적으로 만든 임의 문법이 아님
Neo4J의 Cypher 언어에서 파생되어 이제 SQL 표준의 일부가 된 SQL/PGQ임

행 수준 보안에서 플래너가 행마다 검사한다고? 그게 바로 Row-level security임. 정책을 통과하는 행인지 달리 어떻게 검증하겠음?

PostgreSQL에 행 압축뿐 아니라 블록 압축도 들어오면 좋겠음. 행 압축만으로는 효과가 너무 제한적임
ZFS 풀에 데이터를 두고 블록 압축을 켤 수는 있지만, 네이티브로 지원하면 설정 부담이 없어지고 성능도 더 나을 수 있음

GROUP BY ALL은 생각해보면 정말 말이 되는데, 전에는 한 번도 떠올려본 적이 없어서 재미있음

DevOps에 가까운 관점에서는 PostgreSQL이 연속된 주요 버전 사이의 제자리 업그레이드를 드디어 지원했으면 좋겠음
대부분의 배포판은 pg_upgrade를 위해 구버전과 신버전을 함께 돌리는 성가신 특성을 처리할 수 있지만, Docker를 쓰면 새 주요 버전으로 업그레이드하는 게 정말 고통스러움