PlanetScale, Postgres 전문 검색 확장 TIN 공개. 성능 나오는 버전은 자사 클라우드 전용

로컬 확장은 성능 같은 걸로 안 줌. 클라우드에서만 제 성능 나오고, 깃헙에 올린 lead는 문법 테스트용임. 제목부터 "Postgres용"이 아니라 "우리 호스팅 Postgres용"이라 미스리딩이지.

요즘 이 회사 방식이 다 그럼. Neki도 똑같음. 이런 식이면 쓸 일 자체가 없어짐. 라이선스상 문제는 없지만 개인적으로는 찝찝하더라.

베어메탈을 지원 안 하는 게 제일 아쉬움. 우리 서버에 올려서 쓰고 싶은데 방법이 없음.

SQL 안에서 FTS 하면 관계형 모델이랑 문서 저장 방식이 안 맞아서 늘 불편했음. 나는 SQL은 원본 저장소로 두고 Lucene 인덱스를 따로 굴리는 쪽이 편하더라. 이제 그런 하이브리드가 필요 없을 정도인지 궁금함.

TIN 개발자임. 첫 질문 답은 그냥 "그렇다"임. 두 번째는 TIN이나 PlanetScale이 못 하는 커스터마이징이 뭔지 알려주면 바로 해줄 수 있음.

큰 역색인을 DB 안에 직접 두는 건 흔한 일임. BM25에 유니코드 breakiterator 붙이면 Lucene을 DB에 넣은 셈이라, DB가 이미 큰 곳에서는 오히려 이게 맞음.

모든 DB 회사가 BM25 FTS를 쏟아내는 건 에이전트 코딩 생산성이 현실로 나온 거라 봄. ParadeDB, Timescale, Neon, Databricks가 비슷한 시기에 나왔잖아.

ParadeDB 구현은 Tantivy 크레이트 위에 올린 거라 AI 코딩 훨씬 이전부터 있었음. 이 이론엔 좀 안 맞지.

맞는 말도 있는데, 결국 Postgres 내부를 아는 전문가 팀이 있어야 아키텍처를 그렇게 잡아줄 수 있음. 모델 혼자서는 못 하는 부분임.

진짜 어려운 건 BM25가 아니라 그 주변 스토리지 엔진 작업임. 초당 천 건 업데이트 상황에서 세그먼트 병합 같은 걸 LLM이 잘하겠음? ParadeDB pg_search도 에이전트 코딩 몇 년 전임.

SQLite FTS는 Lucene 쿼리를 기본으로 지원하고 성능도 좋은데 쓰기가 좀 느려짐. Postgres가 그걸 그대로 못 가져오는 이유가 뭔지 궁금했음.

SQLite FTS는 단일 쓰기 락 아래 shadow B-tree를 쓰고, Postgres 인덱스는 posting을 물리적 ctid에 매핑해서 MVCC 가시성 검사와 힙 튜플 변동을 견뎌야 함. 구조가 다름.

tsvector에 gin/gist 쓰는 것보다 TIN이 뭐가 나음? 문서 안 벤치마크 보면 내장 GIN보다 훨씬 빠르더라. GIN이 GiST보다 빠른데 그 위에서 또 빠른 거임.

내장 검색은 20년 넘게 있었지만 코퍼스 전체 통계 쓰는 tfidf, BM25 스코어링은 못 함. 그게 필요 없으면 몰라도, 내 경험엔 결과 품질이 훨씬 나빴음.

몽고DB는 이걸 몇 년 전에 다 갖고 있었는데. 프로덕션을 몽고로 돌리는 게 그냥 행복함.

이거 광고 아님? Postgres 내장 검색도 10년 넘게 있었는데.

깃헙 링크가 안 보임. 이거 21세기식 embrace, extend, extinguish 아님?

PostGIS의 TIN(삼각 불규칙망) 데이터 타입이랑 이름이 겹치는 것 같음. 헷갈릴 듯.