Hacker News 의견

• Postgres를 모든 것에 사용하지 말고, 100명 이상의 엔지니어로 확장할 때는 각 단위가 자체 Postgres를 갖도록 논리적, 물리적 경계를 설정하는 기술적 리더십이 필요함
  • 많은 CTO들이 이 어려운 부분을 수행하지 않음
• Postgres 인덱스가 스킵을 지원하지 않으며, 문자열에 널 문자(\u0000)를 포함할 수 없는 점이 불편함
  • Postgres는 훌륭하지만 몇 가지 이상한 결함이 있음
• 데이터베이스에서 생성된 API를 팀 외부 사람들에게 노출하지 않는 것이 좋음
  • 데이터 저장 방식을 변경하는 데 제한이 생김
  • 이 주제에 대해 이전에 글을 썼으며, 의견이 크게 변하지 않음
• PGQueuer는 Python을 위한 경량 작업 큐로, PostgreSQL을 기반으로 하며 SKIP LOCKED를 사용하여 효율적이고 안전한 작업 처리를 제공함
  • Postgres를 이미 사용 중이고 추가 인프라 없이 Python 네이티브 방식으로 백그라운드 작업을 관리하고 싶다면 PGQueuer를 고려할 만함
• MariaDB/MySQL과 PostgreSQL을 비교한 결과, JSON, 시간 테이블, 컬럼 및 벡터 저장소 등 많은 확장 기능이 존재함을 발견함
  • LISTEN/NOTIFY 기능은 부족하지만, 많은 레거시 앱에서 사용되지 않음에도 불구하고 놀랍게도 따라잡고 있음
• 오픈소스 BM25 검색을 PL/pgSQL에서 제공하며, Rust 확장을 사용할 수 없는 경우에 유용함
  • pgvector와 Reciprocal Rank Fusion을 사용한 하이브리드 검색 제공
• "Amazing CTO"의 기사에서 영감을 받았다는 언급을 보고 기쁨을 느낌
• 하나의 API로 많은 기능에 접근할 수 있는 이점이 많음
  • 메시지 큐와 통합하는 대신 INSERT를 통해 간단하게 처리 가능함
  • 벡터 검색도 당연히 하나의 데이터베이스로 처리 가능함
  • Postgres를 사용하여 HTML을 생성하는 것은 의문이며, 사용자 인터페이스를 만드는 데 적합하지 않을 것 같음
• Postgres 데이터베이스를 자체 호스팅하는 방법에 대한 좋은 자료를 찾고 있음
  • 백업, 최적화 등 최선의 방법을 알고 싶음
• Apache Age를 그래프 데이터에 통합하는 데 2주를 보냈지만, 프로젝트가 오래되고 혼란스러움을 깨달음
  • DGraph로 더 나은 결과를 기대하고 있지만, 그래프 데이터베이스는 불안정한 상태임