PlanetScale released TIN, a new full-text search index for Postgres that handles boolean queries, fuzzy matching, BM25 ranking, and concurrent writes—capabilities existing Postgres search tools lack. In benchmarks against competitors, TIN processed 25-541x more queries per second with dramatically lower latency.

• TIN supports boolean expressions, phrase queries, fuzzy/wildcard/regex matching, BM25 scoring, and handles concurrent updates—a combination no existing Postgres full-text index provides
• Benchmark results show TIN handles 25x more queries/second than ParadeDB and 541x more than Postgres GIN on mixed workloads, with p99 latencies 26-1,356x lower
• With concurrent writes, TIN completed 270,279 updates over 10 minutes while ParadeDB managed 185,584 and pg_textsearch only 735, showing it doesn't sacrifice write performance for read speed

Snowflake interviews Tom Lane, a core Postgres developer for 25 years, about the architectural decisions that have kept the database stable and reliable. He discusses why the process-per-connection model works, how the write-ahead log handles crash recovery, and the trade-offs the project continues to navigate.

• Postgres uses isolated OS processes per connection instead of threads, which simplifies code and improves crash resistance—if one session crashes, it doesn't corrupt shared state or require a full system restart.
• The write-ahead log (WAL) lets transactions commit as soon as log data hits disk, even though table changes may still sit in shared buffers; this batching approach reduces random disk I/O compared to writing scattered changes immediately.
• Connection pooling tools like PgBouncer solve the overhead problem of managing thousands of connections, though the core project hasn't fully integrated pooling into Postgres itself.

Postgres LISTEN/NOTIFY suffers a global exclusive lock on NOTIFY calls, which serializes commits and caps throughput around 2.9K writes/sec. By buffering notifications in memory and flushing them in batched transactions—plus a low-frequency polling fallback—the stream writer can leverage group commits and hit 60K writes/sec with 15–100ms latency.

• Postgres's NOTIFY takes a global exclusive lock at commit held until fsync completes, serializing all notifying transactions and capping throughput around 2.9K writes/sec regardless of spare CPU/IO.
• Batching notifications in memory and flushing them via a single background transaction lets individual writes use group commit instead of serializing on the lock.
• This approach pushed throughput to 60,000 inserts/sec on a single Postgres instance while keeping notify-to-read latency at 15–100ms, with CPU (not locking) as the bottleneck.
• Low-frequency polling as a fallback covers any notifications missed by the batching scheme, trading per-notify durability for table-level durability.

Stash is an open-source service that adds continuous memory to any AI model by storing and organizing session data in PostgreSQL with pgvector. It transforms raw conversations into structured facts, relationships, and patterns, so agents recall preferences, avoid repeated errors, and track long-term goals. Integration via MCP makes it model-agnostic, self-hostable, and free of vendor lock-in.

• Stash gives AI persistent memory by storing conversations in PostgreSQL/pgvector and running a 9-stage pipeline that turns raw episodes into facts, relationships, causal links, patterns, contradictions, goals, and failure detection
• Unlike RAG's static document search, Stash learns automatically from conversations and outcomes without manual tagging, improving over time
• It's model-agnostic and vendor-lock-in-free via MCP integration, working with Claude, GPT, or local models
• Setup requires just three commands (clone repo, configure .env, docker compose up), with self-hosting keeping data local

PgQue is a pure SQL/PLpgSQL event queue for Postgres 14+ that delivers durable, Kafka-style streams without dead tuples or external daemons. It uses snapshot-based batching and TRUNCATE-driven table rotation for stable performance under sustained load. A pg_cron (or any scheduler) ticker drives 1–2 second end-to-end delivery.

• Uses snapshot-based batching with TRUNCATE-driven table rotation instead of per-row UPDATE/DELETE with SKIP LOCKED, avoiding dead tuples, VACUUM pressure, and bloat under sustained load.
• Pure SQL/PLpgSQL install (single file) with pg_cron ticking every second, so it runs on managed Postgres without C extensions or custom builds—unlike PgQ, PGMQ, River, Que, and pg-boss.
• Offers Kafka-style shared event logs with independent per-consumer cursors, rather than one-job-one-worker task queue semantics.
• Delivery latency is 1–2 seconds (tick interval plus polling), with microsecond function execution—fine for durability-focused use but not for sub-millisecond dispatch needs.