OffNet Newsroom

Daily topic roundup

Database Technology

Thursday, August 06, 2026 · 5 stories, curated & summarized — click any story for the source.

Share this roundup on LinkedIn Full edition
AWS What's New awsdatabase

Amazon DynamoDB GA: Real-time vector search with single-digit ms latency

DynamoDB now offers general availability for native vector search, enabling indexing and searching of vector embeddings in real time. The feature delivers single-digit millisecond latency with over 99% recall, addressing the traditional trade-offs between speed, scale, and accuracy as datasets grow to trillions of vectors. Users can store embeddings alongside standard attributes and utilize approximate nearest neighbor searches powered by models from Amazon Bedrock or custom implementations.

  • DynamoDB now supports native vector search for real-time ANN queries at scale.
  • Achieves single-digit millisecond latency with 99%+ recall on billions to trillions of vectors.
  • Store vector embeddings directly alongside existing table attributes without external indexes.
  • Integrates with Amazon Bedrock models or allows custom model generation for embeddings.
  • Eliminates the need for separate vector databases for high-scale, low-latency requirements.
BY THE NUMBERSSingle-digit ms latency with high recall99%Vector search recall rateAchieves high accuracy with single-digit millisecond latency
Read at source →
Hacker News (100+ points) general

Zed launches DeltaDB for embedded AI vector search

Zed has introduced DeltaDB, a vector database designed to run directly within the Zed editor. It enables local, on-device storage and retrieval of embeddings, allowing developers to build AI features without external infrastructure. The tool is tightly integrated into the editor's workflow to support codebase-aware applications.

  • Enables local vector search without cloud dependencies or API latency
  • Tight integration with Zed editor simplifies developer workflows
  • Supports building AI features directly within the IDE environment
  • Reduces infrastructure overhead for small to medium scale applications
Read at source →
Planet PostgreSQL database

PostgreSQL ignore_checksum_failure: Last resort for corrupted data

Christophe Pettus explains the `ignore_checksum_failure` GUC, a parameter that allows PostgreSQL to continue running when data checksums detect corruption. This setting is intended strictly as a temporary emergency measure for scenarios where no backup or failover option exists. It bypasses standard safety checks, making data integrity risks extremely high.

  • Use only when you have no backup or failover path available.
  • Bypasses checksum validation, risking silent data corruption.
  • Treat as a short-term emergency fix, not a permanent solution.
  • Monitor closely and plan immediate recovery or migration.
Read at source →
Planet PostgreSQL database

PostgreSQL HOT Updates: Tuning Fillfactor to Eliminate Vacuum with HammerDB

A HammerDB TPROC-C benchmark demonstrates that tuning the fillfactor parameter can enable Hot Updating (HOT) updates in PostgreSQL, effectively eliminating the need for standard vacuum operations. By optimizing fillfactor to leave sufficient space for row updates within existing pages, the system avoids creating dead tuples that require vacuuming. This approach directly reduces table bloat growth and minimizes the overhead associated with frequent vacuum cycles.

  • Tuning fillfactor enables HOT updates, allowing in-place row modifications without creating new versions.
  • Proper configuration can eliminate vacuum requirements for update-heavy workloads, reducing I/O overhead.
  • Reduced vacuum activity directly correlates with lower table bloat growth in high-update scenarios.
  • HammerDB TPROC-C benchmark validates these gains under standard OLTP conditions.
  • DBAs should monitor vacuum frequency and bloat metrics after adjusting fillfactor settings.
CHECKLISTOptimizing PostgreSQL HOT UpdatesTune fillfactor to enable in-place row modificationsEliminate vacuum requirements for update-heavy workloadsReduce table bloat growth significantlyMonitor vacuum frequency and bloat metricsValidate gains using HammerDB TPROC-C benchmark
Read at source →
Planet PostgreSQL database

PostgreSQL COUNT DISTINCT disables parallel query

Using COUNT DISTINCT in PostgreSQL disables parallel execution for the entire statement, regardless of available cores or workload size. This behavior is hardcoded into the aggregate execution logic and cannot be bypassed with standard indexes or settings. Benchmarks show significant performance penalties on large tables despite the presence of parallel workers for other operations.

  • COUNT DISTINCT forces single-threaded execution, ignoring parallel query settings.
  • No index or parameter tweak can restore parallelism for this specific aggregate.
  • Performance degradation scales with table size, not distinct value count.
  • Monitor analytics workloads for hidden single-thread bottlenecks.
Read at source →
↑