Postgres를 써야하는 이유(펌)

• 대부분의 웹 애플리케이션은 지속적인 데이터 저장이 필요하므로, 새로운 애플리케이션을 만들 때 기본적으로 Postgres를 선택하는 것이 좋음

왜 sqlite가 아닌가?

• sqlite는 좋은 DB지만, 데이터가 하나의 파일에 저장됨
• 이는 애플리케이션이 한 대의 기기에서만 실행된다는 것을 의미함
• 데스크탑 또는 모바일 앱에는 적합하지만, 웹사이트에는 적합하지 않을 수 있음
  • 웹사이트에 sqlite를 사용한 성공 사례가 있지만, 대개 자체 서버와 인프라를 직접 구축한 경우임
• 플랫폼 제공 자동 데이터베이스 백업 및 여러 애플리케이션 서버를 구성하는 기능을 포기해야 할 수도 있음

왜 DynamoDB, Cassandra, 또는 MongoDB가 아닌가?

• 이 데이터베이스들은 뛰어난 성능을 발휘하지만, 전제 조건이 많음:
  • 애플리케이션이 수행해야 할 작업과 접근 패턴을 정확히 알고 있어야 함
  • 매우 큰 데이터 규모로 확장할 필요가 있는 경우
  • 일관성의 일부를 포기할 수 있는 경우
• 이 데이터베이스들은 분산 해시 맵과 유사한 방식으로 작동하므로, 데이터 저장 방식에 쿼리 패턴 지식을 반영해야 함
• 접근(쿼리) 패턴이 바뀌면 데이터 전체를 다시 처리해야 할 수도 있음
• 관계형 데이터베이스는 쉽게 인덱스를 추가하여 쿼리를 수행할 수 있지만, NoSQL 데이터베이스는 그러기 어려움
• 분석 쿼리에는 부적합함
• 대학생이나 신입 개발자가 MongoDB를 사용한다면 도움이 필요할 것임

왜 Valkey가 아닌가?

• Redis로 알려진 이 데이터베이스는 매우 효율적인 캐시로 잘 알려져 있음
• 주 데이터베이스로 사용할 수 있지만 다음과 같은 문제가 있음:
  • 모든 데이터를 RAM에 저장하므로 빠르지만, RAM 용량이 제한적임
  • 데이터 모델링에 있어 타협이 필요함

왜 Datomic이 아닌가?

• 이걸 이미 알고 계시다면 "금색 별"을 드리겠음
• Datomic은 관계형 NoSQL 데이터베이스로 "사전 설계(Up-front Design)" 문제가 없고, 몇가지 깔끔한 속성을 가지고 있음
  • 데이터를 테이블 대신 EAVT(entity-attribute-value-time) 쌍으로 저장하고, 범용 인덱스를 사용함
  • 쿼리를 작성할 때 작성자와 조율할 필요가 없음. 주어진 시간에 '현재 시점'의 데이터베이스를 쿼리하면 됨. 새 데이터, 심지어 삭제(또는 '철회/retractions'라고도 함)도 실제로 이전 데이터를 삭제하지는 않음
• 하지만 몇 가지 단점이 있음:
  • JVM 언어에서만 작동함
  • Clojure 외의 언어에서는 API가 좋지 않음
  • 잘못된 구조의 쿼리로 인해 발생하는 에러 메시지가 매우 불친절함
  • SQL 도구 생태계 같은 것이 없어서 도구가 부족함

왜 XTDB가 아닌가?

• Clojure 사용자들은 많은 데이터베이스를 만듦
• Datomic과 비슷하지만 다음과 같은 특징이 있음:
  • HTTP API를 제공하여 JVM에 종속되지 않음
  • "시스템 시간"과 "유효 시간"의 두 축으로 쿼리 가능함
  • SQL API를 지원함
• 하지만 가장 큰 문제는, 아직 "신생"임. SQL API는 작년에 나왔고, 최근에 전체 스토리지 모델을 변경했음
  • 10년 후에도 살아남을수 있을까? 장기적인 지원 여부가 불확실함

왜 Kafka가 아닌가?

• Kafka는 아주 좋은 "추가 전용(Append-Only)" Log로, TB 단위 데이터 처리에 적합함
• 여러 팀에서 관리하는 여러 서비스에서 유입되는 데이터로 이벤트 소싱 유형의 작업을 수행하려는 경우 놀랍도록 잘 작동gka
• 그러나
  • 작은 규모에서는 Postgres의 테이블로 충분히 대체 가능함
  • Kafka 컨슈머를 만드는 것은 생각보다 오류가 발생하기 쉬움. 결국 로그에서 자신의 위치를 추적해야 하기 때문
  • 추가적인 인프라를 관리해야 함

왜 ElasticSearch가 아닌가?

• 데이터 검색이 제품의 주요 기능이라면 ElasticSearch는 적합한 제품임
  • 데이터를 ETL하고 전체 프로세스를 관리해야 하지만 ElasticSearch는 검색을 위해 만들어졌고, 검색을 잘 수행함
• 하지만 검색이 주된 기능이 아닌 경우 Postgres의 내장 텍스트 검색 기능으로도 충분함
  • 나중에 전용 검색 엔진을 추가할 수 있음

왜 MSSQL 또는 Oracle DB가 아닌가?

• 스스로에게 물어봐야 할 진짜 질문: "가격 대비 가치가 있나요?"
• 라이선스 비용뿐만 아니라 락인 비용도 고려해야 함
• 오라클에 데이터를 저장하면 영구히 Oracle에 비용을 지불하고, 개발자를 계속 교육시켜야 함
  • 엔터프라이즈 기능과 지갑중에서 하나를 영원히 선택해야 함
• 특정 기능이 반드시 필요한 경우가 아니라면 사용을 피하는 것이 좋음
  • MSSQL 없이는 살 수 없는 킬러 기능이 있지 않는한 사용하지 말 것

왜 MySQL이 아닌가?

• 이 부분은 약간 독자의 도움이 필요함
• MySQL은 Oracle이 소유하고 있으며, 일부 기능은 엔터프라이즈 에디션에 잠겨 있음
  • 물론, MySQL은 오랫동안 사용되어 왔으며, 널리 사용되는 무료 에디션이 있음
• 나는 Postgres가 더 나은 선택이라고 믿고 있지만, MySQL에 대한 추가적인 정보가 필요함

왜 AI 벡터 DB가 아닌가?

• 대부분의 AI 벡터 DB는 신생 기술로, 사용에 리스크가 있음
  • AI 버블에 기반한 비즈니스는 신중히 접근해야 함
• 당신의 비즈니스가 또다른 AI grift(사기)일지라도, 그냥 import openai정도면 될 것

왜 Google Sheets가 아닌가?

• 특별한 단점이 없음 필요하다면 사용해도 됨

• MongoDB에 대한 부정적인 의견이 많지만, 대부분 틀린 정보임
  • MongoDB는 초기 단계에서 잘 맞음
  • 데이터 크기가 커질 때도 문제없이 작동함
  • 일관성 문제도 잘 해결됨
  • MongoDB는 Dynamo와 같은 분산 해시 맵이 아님
  • MongoDB의 집계 기능을 잘 모르는 사람들이 많음
  • 신입 개발자가 SQL을 배워야 한다는 이유로 MongoDB를 사용하지 말라는 것은 부당함
• SQLite의 장점
  • 파일 기반이라서 백업이 쉬움
  • ORM을 사용하면 SQLite에서 Postgres로 쉽게 업그레이드 가능함
• 기술적 결함을 지적하는 것은 의미가 없음
  • MongoDB의 Rick Houlihan이 현재 MongoDB에서 일하고 있음
• MySQL에서 Postgres로의 마이그레이션 이유
  • Oracle 소유의 MySQL은 비즈니스 리스크가 있음
  • Postgres는 데이터 일관성을 유지하는 도구가 더 많음
  • Postgres의 확장 기능이 개발 시간을 절약해줌
  • Postgres의 도구 생태계가 더 성숙하고 완전함
• Postgres의 시간 테이블 지원이 부족함
  • SQL:2011 시스템 시간 및 애플리케이션 시간 "이중 시간" 버전 관리가 필요함
  • 복잡한 보고 요구사항이 있는 규제 산업에서는 시간 테이블이 이상적임
• SQLite를 사용하는 이유를 이해하지 못함
  • Postgres 설치가 어렵지 않음
  • SQLite와 Postgres의 차이점에 대한 설명 필요함
• Rick Houlihan의 이름을 잘못 언급한 것에 대한 사과
  • DynamoDB/Cassandra와 MongoDB 비교는 그의 강연에서 나온 것임
  • MongoDB는 비정규화된 정보를 저장하는 데이터베이스로, 접근 패턴 변경에 유연하지 않음
• 아는 것을 사용하고 유용한 것을 배포하는 것이 중요함
• MySQL은 Javascript와 같음
  • 나쁜 결정과 위험 요소가 많음
  • 잘 작동하지만, Postgres가 존재하는데 굳이 사용할 이유가 없음

해커뉴스에서 펌