标签 · Full-Text Search — Glean

Recent picks

2picks · chronological

08-27

PostgreSQL for Everything

Drawing on years as CTO and interim manager, the author argues that PostgreSQL can replace most of your stack: full-text search, document storage, queues, time-series, vector search, cache, even graph databases. He cites Contentful, Instacart and The Guardian as real-world examples, then walks through the mechanisms: tsvector/tsquery, GIN indexes, SELECT ... SKIP LOCKED for queues, UNLOGGED tables for cache-like speed, TimescaleDB for analytics, pgvector for AI retrieval, and Apache AGE for openCypher. The post is a practical starting point for engineers who want to simplify operations, but it is an opinion essay rather than a benchmark-driven study, so the performance claims need validation before adoption.

www.raphaelbauer.com · 13 min · Database · Full-Text Search · PostgreSQL

08-27

SQLite for Everything: Cut Your Stack Down to One File

In this reply to 'PostgreSQL for Everything', the author makes the case that SQLite can collapse an entire stack into one file and one function call. It covers reusable patterns: using BEGIN IMMEDIATE plus RETURNING to turn a table into a durable work queue; indexing JSON via generated columns so schemaless writes get indexed reads; treating FTS5 as a same-transaction search index; and using sqlite-vec so embeddings, documents, metadata and full-text live in the same file, making hybrid search a JOIN. The article cites SQLite's own '35% Faster Than The Filesystem' benchmark, and claims warm-cache point lookups land around 1 microsecond versus roughly 100 microseconds for a localhost Redis GET. It also names real limits: a single writer, serialized concurrent consumers, and the need to move to PostgreSQL or specialized systems once you hit them. Useful for backend and infrastructure engineers who want concrete arguments for cutting components out of their stack before adding new ones.

joecode.com · 16 min · Cache · Database · Full-Text Search