지난주 PGConf에 참가해서 이 발표가 가장 많은 사람들이 몰렸던 세션 중 하나였다는 점이 인상적이었음, 특히 대부분의 세션이 Postgres 자체 개발에 초점을 맞췄던 내향적 컨퍼런스였던 만큼 이 사례 발표가 신선하게 느껴졌음. 많은 팀이 제품이 성공적으로 성장할 때 스택의 특정 부분을 어떻게 확장할지 깊이 알지 못한다는 것을 항상 기억해야 할 필요성, 이 발표는 작은 팀이 어떻게 문제를 극복하며 학습해 나가는지 보여주는 멋진 이야기였다는 평가. "이렇게 하면 안 돼요?" 같은 단순화된 반응보다는, 실제 사용자 이야기로 성장 과정과 제품의 높은 인기를 생생하게 보여줬다는 점에서 내부 개발자 위주의 행사에 딱 맞는 세션이라는 생각. 이 발표의 핵심 메시지는 쓰기 작업이 많지 않으면, 읽기 전용 노드(read replicas)와 단일 마스터 구조만으로도 Postgres를 어마어마한 읽기 처리량까지 확장할 수 있다는 것이라는 점. 이 메시지가야말로 대부분 앱에 해당하는 내용이라는 주장. Q&A 시간에는 주로 Postgres 코어 개발자들이 사용사례를 배우고자 하는 질문 위주였고, 비판하려는 의도는 거의 없었으며 Postgres 커뮤니티가 정말 친절하고 열린 분위기라는 소감
"쓰기 작업이 많지 않다면 단일 마스터와 읽기 전용 레플리카로 Postgres의 읽기 처리량을 크게 확장할 수 있다"는 메시지에 대해, 시스템 디자인 면접을 보며 느낀 건 너무 많은 지원자가 초당 5회 읽기 수준의 간단한 시스템에도 거대한 분산 구조나 결국 일관성이 깨어지는 시스템부터 도입하려 한다는 점이라는 말. 천만 명 유저도 사실 그렇게 큰 규모는 아니라는 주장. 업계 전체가 수평확장에만 몰두하는 동안, 실제 하드웨어가 상상 이상으로 빨라지고 커졌다는 점을 더 많은 이가 인지해야 한다는 바람. Amazon에서 32TB 램 서버를 임대할 수 있는 세상이라는 설명. 규모가 커진 상황에서도 ACID 보장은 여전히 너무 소중하다는 강조
발표 내용이 정말 전달하고 싶었던 핵심 메시지였다며 감사 인사(Bohan)
이 발표의 슬라이드나 녹화본을 볼 수 있는 곳이 있는지 질문
이 스레드가 해당 팀에게 다소 박한 평가라는 인상을 받았다는 의견. 이 분야 경험 많은 HN 유저들은 ChatGPT 같은 대규모 서비스를 어떻게 아키텍처적으로 확장했는지, 거의 무제한 자원을 가진 회사가 어떻게 채용하는지에 흥미를 가지고 있다는 설명. "ORM을 쓰면 비효율적인 쿼리가 쉽게 발생하니 조심해야 한다"라는 발표 메시지 자체가, 해당 팀이 이처럼 대규모 인프라 운영에 아직 경험이 많지 않다는 방증이라는 해석
유연성 차원에서 self-hosting postgres는 매력 있지만(슈퍼유저 권한이나 고급 기능 활용 등), 실제로 직접 운영하는 건 신경이 쓰인다는 느낌. 클라우드 제공업체들도 인덱스를 진짜로 드랍하기 전, 쿼리 플래너에서 인덱스 비활성화 기능을 표준적으로 지원하면 좋겠다는 희망. 대기업이라면 스택 커스터마이징을 위해 self-hosting 선택이 충분히 합리적이라는 생각
(Azure Postgres팀 소속임을 밝혀두며) 오픈AI는 self-host가 아니라 Azure의 매니지드 PostgreSQL(Flexible Server)을 사용하고 있음
오픈AI 스피커(Bohan) 본인이 직접 밝혔는데, self-host 환경이 아니라 Azure Database for PostgreSQL을 사용하고 있음. 발표에서 "Azure Postgres"라고 여러 번 언급하긴 했지만, 마이크로소프트가 관리하는 서비스라는 점을 더 명확히 했어야 했다는 점을 사과
MySQL이나 MariaDB에는 인덱스를 INVISIBLE이나 IGNORED로 만들어 쿼리 플래너에서 무시하게 하는 DDL이 있는데, 이와 비슷한 기능이 Postgres에는 없는 것이 놀랍다는 의견
"Self-hosting postgres 의 장점은 유연함…"이란 원문을 인용만 함
스키마 변경 이벤트(컬럼 추가/삭제 등) 히스토리 기록 기능이 필요하다는 요청에 대해, 이미 EVENT TRIGGER를 활용해 실시간으로 구현 가능하며, 예시로 Aquameta(https://github.com/aquametalabs/aquameta)에서 구현 사례를 참고할 수 있다는 안내
우리도 자체 Postgres 환경에 DDL 변경 이력관리 기능을 구현 중이라는 설명. Postgres 자체가 강력해서 다양한 방식으로 구현 가능하지만, 이력관리와 대규모/중요 DB 운영 기록(log)도 매우 흔한 요구사항이라는 점. 대부분은 직접 뼈저리게 경험해보기 전까지 중요성을 모른다는 주장. DDL 변경뿐 아니라, 주요 운영 정책(예: 가격 모델 변경, SKU/가격 커스텀 등)이 반영될 때도 반드시 "감사 가능성"을 확보해야 한다는 설명. 완전히 릴레이션 모델을 설계하다 보면 실제 앱에선 자주 바뀌는 테이블은 일부이고, 대다수는 거의 변경 없는 "정적(static)" 테이블이라는 점, 이러한 테이블이 바뀔 때는 그 이력을 꼼꼼히 남겨야 과거 데이터 해석 혹은 롤백에 유리하다는 주장
우리(Xata)는 pgroll(https://github.com/xataio/pgroll)과 pgstream(https://github.com/xataio/pgstream) 모두 EVENT TRIGGER로 DDL 변경을 감지하여 스키마 마이그레이션 이력을 남기거나, 스키마 변경 이벤트를 논리적 복제 스트림에 포함시키는 기능을 사용하고 있음. 단, 대부분의 Postgres 기반 DBaaS에서는 EVENT TRIGGER를 슈퍼유저 권한 때문에 일부 제한하고, RDS/Aurora와 Xata는 지원, Supabase도 지원 준비 중이라는 정보
Aquameta를 기억해줘서 고맙고, 곧 멋진 새 기능이 나온다는 티징
이 내용(대규모에서의 인덱스 동시 생성, 테이블 리라이트 회피, 트래픽 분산, 트랜잭션 타임아웃, 읽기 레플리카 등)은 사실 오픈AI보다 훨씬 작은 규모 운영에서도 거의 필수(상식)라는 주장. Postgres에 바라는 요구사항도 사실 예전부터 다들 요구해왔던 내용이고, "Next Level"이라고 제목 붙였지만 실제론 싱글 마스터를 필사적으로 유지하며 확장 중인 모습[신규 워크로드 제한있는 상황]에 가깝다는 견해. 대규모 읽기 부하를 무난하게 견디는 게 핵심 포인트인데, 이 자체는 이미 읽기 레플리카와 수평분산의 정석이라는 설명. 인덱스를 disable하는 방법(내부 필드(indisvalid) 조작)도 공식적으로는 제공되지 않는 트릭이고, 이런 식의 시스템 카탈로그 트윅은 위험하다는 경고. 모니터링 뷰로 인덱스 사용 여부를 체크해서 드랍하라는 주장도 완벽한 해결책은 아니며, 어떤 인덱스가 필요/불필요한지 더 명확히 하려면 쿼리 플랜까지 확인해야 신뢰성을 가질 수 있다는 설명
TFA(원문 기사)는 오픈AI가 Azure에서 초당 100만 쿼리를 처리하고 있다고 하는데, 이 정도 수준은 실제 클라우드 환경, 특히 네트워크 기반 스토리지 사용 환경에서는 상당히 인상적이라는 해석. 다만 전체적으로 약 40개 읽기 레플리카에 분산된 값이므로 단일 인스턴스당 2.5만 QPS 수준이라 그리 놀랍지는 않다는 의견. 인덱스 사용 여부 논쟁에 대해서는, 최신 통계와 DB 특성만 제대로 파악한다면 인덱스 어느 것을 쓰는 것이 적절한지, 쿼리의 조건/프로젝션이 인덱스의 left-most prefix를 잘 따르는지만 체크하면 충분하다는 설명
오픈AI가 Postgres 샤딩을 하지 않는 이유에 대해 아무런 설명도 없는데, 사실 답답하다고 지적. 유저 단위 샤딩만 해도 훨씬 더 쉽게 문제가 풀릴 것 같은데 왜 싱글 마스터를 고수하는지 의문
물리적 복제를 사용하는 것 같던데, 나는 현재 비용 절감(리전 간 나가는 트래픽 줄이기) 목적으로 논리 복제로 전환 고려 중이라는 고민. Postgres 17 이후로 네이티브 논리복제 기능이 많이 발전한 것 같은데, 실전에서 해볼 만한지 의견이 궁금
다양한 쿼리에 대응하려면 다른 스토리지 엔진(키-값, 검색, 벡터 검색, 캐시 등)도 병행하고 있을텐데, 발표 내용은 오직 Postgres에 집중한 점이 이상하다는 지적. 실제로 내부적으로는 다양한 방식으로 트래픽 분산/부하 분산하는 여러 전략을 펼치고 있을 것 같다는 추정
쓰기 인스턴스만 로컬 고속 SSD를 단 전용 서버에서 직접 운영하고, 읽기는 매니지드 서비스에서만 처리하면 더 좋은 성능이 가능할지 궁금하다는 생각
"DB 샤드 좀 해라"는 강한 주장. 유저/조직 단위로 샤딩만 해도 현재 겪는 주요 문제를 간단히 해결할 수 있을 거라는 견해. 복잡한 우회책을 여러 번 시도하는 게 오히려 돌아가는 셈이라는 불만
발표에서는 굳이 샤딩 없이도 단일 마스터 구조만으로도 엄청난 처리량까지 확장 가능하다는 점이 핵심 메시지였으며, 당연히 샤딩도 검토했지만 트레이드오프가 맞지 않아 현재 구조로도 확장이 된다는 경험
오픈AI의 발표자(Bohan) 직접 답변: 워크로드 샤딩이 쉬운 상황은 아니고, 이미 쓰기 부하가 많은 워크로드는 PostgreSQL에서 분리해 샤드로 처리하고 남아있는 것은 거의 읽기 전용이어서 샤딩 도입이 엄청난 노력이 들어간다는 설명. 현재는 Azure Database for PostgreSQL만으로도 충분히 확장성 확보 및 미래 수용 여력까지 있다는 판단. 다만 장기적으로 샤딩을 완전히 배제할 생각은 아니고, 단기 우선순위는 아니라는 메시지
샤딩이 생각만큼 단순하지 않다는 주장. 강력한 DB를 쓰는 이유는 복잡한 데이터 분석/질의가 가능하기 때문이며, 단순 저장/분산만 목적이라면 차라리 여러 NFS 마운트 쓰는 게 더 간단하다는 설명
초당 백만 쿼리처럼 무지막지한 DB에 샤딩을 단순하게 적용하라고 하는 건 쉽지 않은 일이라는 현실감 있는 피드백. 조직 단위가 샤딩 키로 자연스러워 보이긴 해도, 이 정도 스케일부터는 단순한 게 하나도 없다는 의견
위 논지에 적극 동의한다는 반응
ORM을 조심해서 쓰라는 발표 언급에 대해, 모든 ORM(특히 다중 DB 호환형 ORM)이 문제라고 생각한다는 본인의 입장. ORM을 쓰다 보면 데이터 패턴을 어플리케이션 코드 수준으로만 생각하게 만들고, 결국 DB마다 제공하는 강력한 기능을 거의 못 쓰게만든다는 주장. 본인은 ORMs를 전혀 쓰지 않고 Postgres 전용 쿼리/기능을 적극적으로 활용, 언어나 편의성보다 DB 파워에 집중하는 것이 훨씬 이득이라는 설명. 결국 좋은 SQL을 직접 작성하는 게 전체 시스템에 행복을 가져다준다는 결론
예전에 DB2에서 psql로 마이그레이션할 때, 다운타임 최소화를 위해 ORM이 큰 도움이 되었던 경험. ORM 덕분에 DB 스위칭이 투명하게 가능했고, 대부분의 로직을 거의 건드리지 않아도 되었으며, 모든 개발자가 직접 쿼리 작성에 익숙하지 않거나 코드에 쿼리가 섞이면 리팩터링/이해가 매우 어려워진다는 주장. 결국 SQL도 라이브러리로 추상화될 것이라는 설명
Django ORM을 오랫동안 쓰며 정말 뛰어난 소프트웨어라는 인상을 받았지만, 최근 sqlc를 쓰면서 쿼리를 Go 코드로 바로 바꿔주는 형태가 오히려 ORM과 raw SQL 사이의 이상적인 타협점이라는 생각
진짜 좋은 ORM(예: Entity Framework Core) 경험을 못 해봤을 뿐이라는 입장
제목은 "Scaling PostgreSQL to the Next Level at OpenAI"가 진짜 발표 제목에 맞는 것 같다는 가벼운 피드백
Hacker News 의견
지난주 PGConf에 참가해서 이 발표가 가장 많은 사람들이 몰렸던 세션 중 하나였다는 점이 인상적이었음, 특히 대부분의 세션이 Postgres 자체 개발에 초점을 맞췄던 내향적 컨퍼런스였던 만큼 이 사례 발표가 신선하게 느껴졌음. 많은 팀이 제품이 성공적으로 성장할 때 스택의 특정 부분을 어떻게 확장할지 깊이 알지 못한다는 것을 항상 기억해야 할 필요성, 이 발표는 작은 팀이 어떻게 문제를 극복하며 학습해 나가는지 보여주는 멋진 이야기였다는 평가. "이렇게 하면 안 돼요?" 같은 단순화된 반응보다는, 실제 사용자 이야기로 성장 과정과 제품의 높은 인기를 생생하게 보여줬다는 점에서 내부 개발자 위주의 행사에 딱 맞는 세션이라는 생각. 이 발표의 핵심 메시지는 쓰기 작업이 많지 않으면, 읽기 전용 노드(read replicas)와 단일 마스터 구조만으로도 Postgres를 어마어마한 읽기 처리량까지 확장할 수 있다는 것이라는 점. 이 메시지가야말로 대부분 앱에 해당하는 내용이라는 주장. Q&A 시간에는 주로 Postgres 코어 개발자들이 사용사례를 배우고자 하는 질문 위주였고, 비판하려는 의도는 거의 없었으며 Postgres 커뮤니티가 정말 친절하고 열린 분위기라는 소감
"쓰기 작업이 많지 않다면 단일 마스터와 읽기 전용 레플리카로 Postgres의 읽기 처리량을 크게 확장할 수 있다"는 메시지에 대해, 시스템 디자인 면접을 보며 느낀 건 너무 많은 지원자가 초당 5회 읽기 수준의 간단한 시스템에도 거대한 분산 구조나 결국 일관성이 깨어지는 시스템부터 도입하려 한다는 점이라는 말. 천만 명 유저도 사실 그렇게 큰 규모는 아니라는 주장. 업계 전체가 수평확장에만 몰두하는 동안, 실제 하드웨어가 상상 이상으로 빨라지고 커졌다는 점을 더 많은 이가 인지해야 한다는 바람. Amazon에서 32TB 램 서버를 임대할 수 있는 세상이라는 설명. 규모가 커진 상황에서도 ACID 보장은 여전히 너무 소중하다는 강조
발표 내용이 정말 전달하고 싶었던 핵심 메시지였다며 감사 인사(Bohan)
이 발표의 슬라이드나 녹화본을 볼 수 있는 곳이 있는지 질문
이 스레드가 해당 팀에게 다소 박한 평가라는 인상을 받았다는 의견. 이 분야 경험 많은 HN 유저들은 ChatGPT 같은 대규모 서비스를 어떻게 아키텍처적으로 확장했는지, 거의 무제한 자원을 가진 회사가 어떻게 채용하는지에 흥미를 가지고 있다는 설명. "ORM을 쓰면 비효율적인 쿼리가 쉽게 발생하니 조심해야 한다"라는 발표 메시지 자체가, 해당 팀이 이처럼 대규모 인프라 운영에 아직 경험이 많지 않다는 방증이라는 해석
유연성 차원에서 self-hosting postgres는 매력 있지만(슈퍼유저 권한이나 고급 기능 활용 등), 실제로 직접 운영하는 건 신경이 쓰인다는 느낌. 클라우드 제공업체들도 인덱스를 진짜로 드랍하기 전, 쿼리 플래너에서 인덱스 비활성화 기능을 표준적으로 지원하면 좋겠다는 희망. 대기업이라면 스택 커스터마이징을 위해 self-hosting 선택이 충분히 합리적이라는 생각
Postgres에서 특정 인덱스를 활용하거나 비활성화하는 다양한 방법이 이미 있고, 클라우드 매니지드 Postgres 인스턴스에서도 쓸 수 있다는 설명. 대표적으로 쿼리 플래너 세팅을 쿼리별로 조정(예: enable_indexscan=off)하거나, where절에 간단한 사칙연산 넣어서 의도적으로 인덱스를 쓰지 않게 하는 방법, 그리고 pg_hintplan 익스텐션(주석문으로 어느 인덱스를 쓰라고 힌트를 줄 수 있음, 참고: https://pg-hint-plan.readthedocs.io/en/latest/hint_table.html#hints-for-scan-methods)
(Azure Postgres팀 소속임을 밝혀두며) 오픈AI는 self-host가 아니라 Azure의 매니지드 PostgreSQL(Flexible Server)을 사용하고 있음
오픈AI 스피커(Bohan) 본인이 직접 밝혔는데, self-host 환경이 아니라 Azure Database for PostgreSQL을 사용하고 있음. 발표에서 "Azure Postgres"라고 여러 번 언급하긴 했지만, 마이크로소프트가 관리하는 서비스라는 점을 더 명확히 했어야 했다는 점을 사과
MySQL이나 MariaDB에는 인덱스를 INVISIBLE이나 IGNORED로 만들어 쿼리 플래너에서 무시하게 하는 DDL이 있는데, 이와 비슷한 기능이 Postgres에는 없는 것이 놀랍다는 의견
"Self-hosting postgres 의 장점은 유연함…"이란 원문을 인용만 함
스키마 변경 이벤트(컬럼 추가/삭제 등) 히스토리 기록 기능이 필요하다는 요청에 대해, 이미 EVENT TRIGGER를 활용해 실시간으로 구현 가능하며, 예시로 Aquameta(https://github.com/aquametalabs/aquameta)에서 구현 사례를 참고할 수 있다는 안내
우리도 자체 Postgres 환경에 DDL 변경 이력관리 기능을 구현 중이라는 설명. Postgres 자체가 강력해서 다양한 방식으로 구현 가능하지만, 이력관리와 대규모/중요 DB 운영 기록(log)도 매우 흔한 요구사항이라는 점. 대부분은 직접 뼈저리게 경험해보기 전까지 중요성을 모른다는 주장. DDL 변경뿐 아니라, 주요 운영 정책(예: 가격 모델 변경, SKU/가격 커스텀 등)이 반영될 때도 반드시 "감사 가능성"을 확보해야 한다는 설명. 완전히 릴레이션 모델을 설계하다 보면 실제 앱에선 자주 바뀌는 테이블은 일부이고, 대다수는 거의 변경 없는 "정적(static)" 테이블이라는 점, 이러한 테이블이 바뀔 때는 그 이력을 꼼꼼히 남겨야 과거 데이터 해석 혹은 롤백에 유리하다는 주장
우리(Xata)는 pgroll(https://github.com/xataio/pgroll)과 pgstream(https://github.com/xataio/pgstream) 모두 EVENT TRIGGER로 DDL 변경을 감지하여 스키마 마이그레이션 이력을 남기거나, 스키마 변경 이벤트를 논리적 복제 스트림에 포함시키는 기능을 사용하고 있음. 단, 대부분의 Postgres 기반 DBaaS에서는 EVENT TRIGGER를 슈퍼유저 권한 때문에 일부 제한하고, RDS/Aurora와 Xata는 지원, Supabase도 지원 준비 중이라는 정보
Aquameta를 기억해줘서 고맙고, 곧 멋진 새 기능이 나온다는 티징
이 내용(대규모에서의 인덱스 동시 생성, 테이블 리라이트 회피, 트래픽 분산, 트랜잭션 타임아웃, 읽기 레플리카 등)은 사실 오픈AI보다 훨씬 작은 규모 운영에서도 거의 필수(상식)라는 주장. Postgres에 바라는 요구사항도 사실 예전부터 다들 요구해왔던 내용이고, "Next Level"이라고 제목 붙였지만 실제론 싱글 마스터를 필사적으로 유지하며 확장 중인 모습[신규 워크로드 제한있는 상황]에 가깝다는 견해. 대규모 읽기 부하를 무난하게 견디는 게 핵심 포인트인데, 이 자체는 이미 읽기 레플리카와 수평분산의 정석이라는 설명. 인덱스를 disable하는 방법(내부 필드(indisvalid) 조작)도 공식적으로는 제공되지 않는 트릭이고, 이런 식의 시스템 카탈로그 트윅은 위험하다는 경고. 모니터링 뷰로 인덱스 사용 여부를 체크해서 드랍하라는 주장도 완벽한 해결책은 아니며, 어떤 인덱스가 필요/불필요한지 더 명확히 하려면 쿼리 플랜까지 확인해야 신뢰성을 가질 수 있다는 설명
TFA(원문 기사)는 오픈AI가 Azure에서 초당 100만 쿼리를 처리하고 있다고 하는데, 이 정도 수준은 실제 클라우드 환경, 특히 네트워크 기반 스토리지 사용 환경에서는 상당히 인상적이라는 해석. 다만 전체적으로 약 40개 읽기 레플리카에 분산된 값이므로 단일 인스턴스당 2.5만 QPS 수준이라 그리 놀랍지는 않다는 의견. 인덱스 사용 여부 논쟁에 대해서는, 최신 통계와 DB 특성만 제대로 파악한다면 인덱스 어느 것을 쓰는 것이 적절한지, 쿼리의 조건/프로젝션이 인덱스의 left-most prefix를 잘 따르는지만 체크하면 충분하다는 설명
오픈AI가 Postgres 샤딩을 하지 않는 이유에 대해 아무런 설명도 없는데, 사실 답답하다고 지적. 유저 단위 샤딩만 해도 훨씬 더 쉽게 문제가 풀릴 것 같은데 왜 싱글 마스터를 고수하는지 의문
물리적 복제를 사용하는 것 같던데, 나는 현재 비용 절감(리전 간 나가는 트래픽 줄이기) 목적으로 논리 복제로 전환 고려 중이라는 고민. Postgres 17 이후로 네이티브 논리복제 기능이 많이 발전한 것 같은데, 실전에서 해볼 만한지 의견이 궁금
다양한 쿼리에 대응하려면 다른 스토리지 엔진(키-값, 검색, 벡터 검색, 캐시 등)도 병행하고 있을텐데, 발표 내용은 오직 Postgres에 집중한 점이 이상하다는 지적. 실제로 내부적으로는 다양한 방식으로 트래픽 분산/부하 분산하는 여러 전략을 펼치고 있을 것 같다는 추정
쓰기 인스턴스만 로컬 고속 SSD를 단 전용 서버에서 직접 운영하고, 읽기는 매니지드 서비스에서만 처리하면 더 좋은 성능이 가능할지 궁금하다는 생각
"DB 샤드 좀 해라"는 강한 주장. 유저/조직 단위로 샤딩만 해도 현재 겪는 주요 문제를 간단히 해결할 수 있을 거라는 견해. 복잡한 우회책을 여러 번 시도하는 게 오히려 돌아가는 셈이라는 불만
발표에서는 굳이 샤딩 없이도 단일 마스터 구조만으로도 엄청난 처리량까지 확장 가능하다는 점이 핵심 메시지였으며, 당연히 샤딩도 검토했지만 트레이드오프가 맞지 않아 현재 구조로도 확장이 된다는 경험
오픈AI의 발표자(Bohan) 직접 답변: 워크로드 샤딩이 쉬운 상황은 아니고, 이미 쓰기 부하가 많은 워크로드는 PostgreSQL에서 분리해 샤드로 처리하고 남아있는 것은 거의 읽기 전용이어서 샤딩 도입이 엄청난 노력이 들어간다는 설명. 현재는 Azure Database for PostgreSQL만으로도 충분히 확장성 확보 및 미래 수용 여력까지 있다는 판단. 다만 장기적으로 샤딩을 완전히 배제할 생각은 아니고, 단기 우선순위는 아니라는 메시지
샤딩이 생각만큼 단순하지 않다는 주장. 강력한 DB를 쓰는 이유는 복잡한 데이터 분석/질의가 가능하기 때문이며, 단순 저장/분산만 목적이라면 차라리 여러 NFS 마운트 쓰는 게 더 간단하다는 설명
초당 백만 쿼리처럼 무지막지한 DB에 샤딩을 단순하게 적용하라고 하는 건 쉽지 않은 일이라는 현실감 있는 피드백. 조직 단위가 샤딩 키로 자연스러워 보이긴 해도, 이 정도 스케일부터는 단순한 게 하나도 없다는 의견
위 논지에 적극 동의한다는 반응
ORM을 조심해서 쓰라는 발표 언급에 대해, 모든 ORM(특히 다중 DB 호환형 ORM)이 문제라고 생각한다는 본인의 입장. ORM을 쓰다 보면 데이터 패턴을 어플리케이션 코드 수준으로만 생각하게 만들고, 결국 DB마다 제공하는 강력한 기능을 거의 못 쓰게만든다는 주장. 본인은 ORMs를 전혀 쓰지 않고 Postgres 전용 쿼리/기능을 적극적으로 활용, 언어나 편의성보다 DB 파워에 집중하는 것이 훨씬 이득이라는 설명. 결국 좋은 SQL을 직접 작성하는 게 전체 시스템에 행복을 가져다준다는 결론
예전에 DB2에서 psql로 마이그레이션할 때, 다운타임 최소화를 위해 ORM이 큰 도움이 되었던 경험. ORM 덕분에 DB 스위칭이 투명하게 가능했고, 대부분의 로직을 거의 건드리지 않아도 되었으며, 모든 개발자가 직접 쿼리 작성에 익숙하지 않거나 코드에 쿼리가 섞이면 리팩터링/이해가 매우 어려워진다는 주장. 결국 SQL도 라이브러리로 추상화될 것이라는 설명
Django ORM을 오랫동안 쓰며 정말 뛰어난 소프트웨어라는 인상을 받았지만, 최근 sqlc를 쓰면서 쿼리를 Go 코드로 바로 바꿔주는 형태가 오히려 ORM과 raw SQL 사이의 이상적인 타협점이라는 생각
진짜 좋은 ORM(예: Entity Framework Core) 경험을 못 해봤을 뿐이라는 입장
제목은 "Scaling PostgreSQL to the Next Level at OpenAI"가 진짜 발표 제목에 맞는 것 같다는 가벼운 피드백