Copy-and-Replay vs Branch-at-a-Point: Two Backup Recovery Paths
A side-by-side comparison of copy-and-replay recovery and branch-at-a-point restores, showing why restore time scales with data size in one model and not the other.
Loading…
Topic
298 posts about Postgres. Every summary links to the original.
See the idea
A side-by-side comparison of copy-and-replay recovery and branch-at-a-point restores, showing why restore time scales with data size in one model and not the other.
Agent memory is the knowledge that survives a run, not the working state inside one. This explainer separates the two, then maps the write path, the read path, and the database limits that cap recall.
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
Newest first
Papers with Code needs a search engine that supports exact titles and arXiv identifiers, semantic requests, navigational queries, typos, and fast responses when model services are cold or unavailable. The system uses hybrid retrieval: PostgreSQL full-text search provides a lexical baseline, pgvector stores dense embeddings, and reciprocal rank fusion combines them. Full-corpus embeddings for more than 110,000 papers run in burstable GPU Jobs from repeatable-read database snapshots, with checksummed JSONL inputs and resumable Parquet outputs stored in Buckets. An Inference Endpoint serves low-latency query embeddings and bounded hourly updates for changed papers, while lexical retrieval remains a fallback. The embedding contract pins the model revision, dimension, prompts, normalization, and source hash; production uses Qwen/Qwen3-Embedding-0.6B with 256-dimensional L2-normalized vectors, and stored vectors also support related-paper retrieval without a request-time model call.
At POSETTE 2026, Sai Srirampur’s talk examines how storage limits can produce slow ingestion, erratic P95 reads, lagging autovacuum, slower checkpoints, and logical replication lag in large PostgreSQL workloads. The benchmark ran the same 3.3-billion-row, random-UPDATE workload on four local-NVMe clusters and four baseline gp3 EBS clusters, using m6id.4xlarge instances, 64 clients, and 16 worker threads. NVMe reached median 16,030 TPS versus 1,734 TPS on EBS, reduced median latency from 36.9 ms to 4.0 ms, and completed the tested VACUUM and replication-backlog tasks faster. The analysis attributes most of the gap to storage waits rather than CPU work, while the proposed production model combines local NVMe with quorum-based replication, external base backups, and archived WAL for recovery.
According to the 2026 Django Developers Survey, ninety percent of respondents incorporate artificial intelligence into their weekly or daily workflows. While agents generate code rapidly, developers remain accountable for understanding, evaluating, and shipping changes within their applications. PyCharm addresses these demands by integrating support for external agents, local models via Ollama and LM Studio, and customizable agent skills across codebases. The IDE maintains version-specific framework assistance, including auto-completion for Django 6.0 template partials, alongside architectural inspection tools and visual diffs. Furthermore, developers can trace application components, inspect API endpoints, execute HTTP requests, and query database migrations directly through built-in tooling.
Databricks Feature Store addresses the lag between batch-computed machine-learning features and decisions that depend on events from seconds earlier. It lets a feature definition drive both offline batch processing and online streaming pipelines, orchestrating Kafka ingestion, Spark Real-Time Mode (RTM), Lakebase, and Model Serving. For a rolling 10-minute transaction sum, RTM updates per entity state in local RocksDB, expires contributions per event, and writes revised values to Lakebase through a streaming JDBC sink. The described path reports end-to-end p99 200ms latency from Kafka arrival to online feature availability, while Model Serving retrieves declared dependencies automatically at inference. Tumbling and sliding windows remain options when fewer, cheaper updates are acceptable.
pg_clickhouse v0.10.0 expands pushdown for analytic workloads, with full pushdown across the TPC-H suite remaining the stated target. The release moves the scoreboard from 12 of 22 fully pushed-down queries to 16, including Q17, which falls from 32.7 seconds to 37 milliseconds when its correlated aggregate subquery is shipped to ClickHouse. SubPlan handling now turns PostgreSQL subqueries into ClickHouse subqueries, while NOT IN and related operators receive guards that preserve PostgreSQL’s three-valued NULL semantics; compatibility requires ClickHouse 25.8 or later for the correlated-subquery shape. The binary driver was rebuilt on a plain-C client library and hardened against concurrency bugs. The release also broadens pushed-down functions and aggregates, adds clickhouse_perform() and clickhouse_server_version(), and leaves six TPC-H queries plus other roadmap items unresolved.
Databricks says Electric is joining the company to extend its Postgres capabilities from the lakehouse to AI agent sandboxes. The post frames agentic applications as requiring both durable governed state and rapidly changing local context: agents choose data at runtime, operate in sandboxed environments where cloud databases are reached over the network, and collaborate while working in parallel. Electric’s PGlite is a lightweight Postgres database built for WebAssembly that runs inside an agent, application, browser tab, or device, while its real-time sync engine synchronizes distributed data with centralized Lakebase infrastructure. PGlite’s weekly downloads reportedly grew from 1 million to 13 million in twelve months, and the sync architecture is described as keeping agents’ shared context current. Combined, Lakebase, PGlite, and synchronization are presented as a Postgres-based foundation for collaborative agentic applications at production scale.
Supabase is now available as a connector on Perplexity Computer, allowing the agent to use a Supabase project as a persistent data layer across runs. Computer can read from and write to Postgres tables, answer questions by running queries, retrieve user and payment data for support debugging, and invoke Edge Functions with test payloads. Recurring queries can be scheduled, with results posted to Slack, while workflows can combine Supabase data with Stripe events and route fixes through GitHub pull requests. The announcement presents the connector as a way to keep database work inside Computer’s multi-step workflows across more than 400 apps, without custom glue code.
ClickHouse reports a set of updates to its Managed Postgres beta, aimed at simplifying onboarding and advancing its unified Postgres-and-ClickHouse data stack. The redesigned flow supports sample-data loading or PostgreSQL migration through ClickPipes, built-in SQL exploration, replication to ClickHouse, and cross-system queries through pg_clickhouse; services also notify users when disk usage remains above 85%, with console, email, and optional Slack channels. Observability now includes searchable PostgreSQL logs, CPU, memory, disk, IOPS, connection and per-table metrics, query insights, a Prometheus-compatible /metrics endpoint, and an OpenAPI slow-query API. Backups use more CPU and disk throughput on larger servers, making backup and restore times predictable even on 10+ TB servers, while extensions add pg_re2 and improvements to pg_clickhouse and pg_stat_ch, including regex pushdown, Arrow batching, sampling, and safer worker exits; Google Cloud Platform availability and further maintenance, configuration, and integration work are planned.
Physical Intelligence, which builds robotics foundation models, needed a data stack that could support both transactional operations and high-cardinality analytical workloads. Its previous single RDS Postgres instance could not handle those demands, so the team migrated to ClickHouse Cloud and adopted Postgres managed by ClickHouse for OLTP alongside ClickHouse for OLAP. Postgres is automatically replicated into ClickHouse through ClickPipes, while materialized views, full-text indices, and a query agent help researchers search across the company’s data. The resulting stack supports faster, easier exploration as data volume grows from the 10 billion to 100 billion row range, and also handles telemetry through ClickHouse with ClickStack and Grafana.
Postgres writes every change to the write-ahead log (WAL), and Managed Postgres uploads completed segments to object storage for point-in-time recovery; if uploads lag, retained WAL can fill the disk and cause a PANIC shutdown. ClickHouse Managed Postgres counters this with a data-plane systemd timer that checks pending segments every 15 seconds and uses cgroup v2 I/O controls to throttle client write bandwidth at 80%, 50%, or 20% of provisioned throughput as backlog thresholds rise. The drain path—including the archiver, checkpointer, and related processes—is placed in an immune cgroup, while client backends are throttled and reads remain uncapped. In a test with a 500 MB/s gp3 volume and an archive limited to 4 MB/s, the backlog reached 3,433 segments and 53 GiB before recovery. Once the limit was removed, the archiver cleared the queue, the throttle released automatically, and the disk stayed below 33% full.
Postgres Changes now supports filters composed across multiple columns, additional operators, and column selection for subscriptions over Postgres tables. It can receive insert, update, and delete events over WebSockets, while comma-separated conditions or the postgresChangesFilter builder combine conditions with AND. New operators include like, ilike, is, match, imatch, isdistinct, and negated forms, while selected payloads always include the table's primary key. Column selection is opt-in, requires @supabase/supabase-js 2.109.0 or newer, and columns must be selectable by the subscribing role; Row Level Security still applies. These changes can lower billable usage because rejected events avoid messages per subscriber and trimmed payloads send fewer egress bytes, although DELETE events carry only the primary key and OR composition is unsupported.
ClickHouse announced the launch of ClickHouse Labs, a new research group led by Andy Pavlo, who joins as Vice President of Database Research. The group is intended to advance foundational work in database systems and share it openly with the broader community. Its research spans database and data architectures, query processing, systems performance, and infrastructure for both ClickHouse and PostgreSQL, with applications including real-time analytics, data warehousing, observability, and AI. Researchers will build and test ideas against demanding real-world workloads, collaborate with ClickHouse engineers, and publish findings in leading research venues so others can evaluate, extend, and build on them.
Andy Pavlo announces that he is joining ClickHouse to establish and lead ClickHouse Labs, an industry research team focused on database systems. He describes ClickHouse’s early use of C++ and vectorized query execution with SIMD in 2016, and says its development has remained relevant to his academic research. Labs will work directly with ClickHouse engineers, customers, collaborators, and industry partners rather than operating separately, while also collaborating with the PostgreSQL team on performance and reliability for its managed service. An immediate priority is validating and pushing an existing backlog of ideas and optimizations into production, followed by research into hardware, algorithms, data structures, execution strategies, and DBMS development for AI and agentic workloads. The stated aim is to combine scientific research with technology that matters to users.
This third part describes joining Backstage’s live operational Postgres catalog with analytical billing data so teams can query resource ownership and cloud spend together. Lakebase isolates compute per workload, allowing portal traffic and FinOps queries to use the same underlying storage; benchmarked catalog queries ran at 55–65 ms end-to-end and searches at two to four ms. Because Lakehouse Federation’s Postgres connector accepts static credentials while Lakebase applications use OAuth JWTs, the proof-of-concept creates a separate SCRAM-SHA-256 Postgres role for federation. This enables a single query to join Backstage resource names with Unity Catalog’s system.billing.usage without data movement, while branch billing remains visible per branch and endpoint. The operational considerations include password rotation, read-only grants, branch TTLs, and scale-to-zero endpoints that stop billing when idle.
Media buying remains slowed by fragmented coordination across emails, spreadsheets, PDFs, and phone calls, leaving teams to research inventory, compare pricing, negotiate, and issue orders manually. The post presents an agentic workflow in which buyer and seller agents discover inventory, negotiate prices, and book deals through IAB Tech Lab’s AAMP standards, including AdCOM, OpenDirect, OpenRTB deals, and registry-based discovery and trust. Its Databricks implementation runs self-contained applications on Databricks Apps, with CrewAI agent crews using Databricks Foundation Model APIs and Claude models, Lakebase providing transactional Postgres state, and MLflow tracing capturing decisions and tool calls. The example processes a $200,000 Q3 Brand Launch across CTV and Linear TV with a $38 CPM ceiling, and is packaged as a Databricks Automation Bundle accelerator deployable with a single command.
CLA and Databricks built a production document-processing application for auditing that reduces extraction time from hours to minutes without compromising quality, using Databricks-native services including Lakebase Postgres, Databricks Apps, Lakeflow Jobs, MLflow, and Unity Catalog Volumes. Lakebase serves as the orchestration layer’s single source of truth for tasks and execution attempts, coordinating long-running work, retries, leases, priorities, rate limits, costs, and status visibility. The queue uses Postgres patterns including FOR UPDATE SKIP LOCKED, priority and FIFO ordering, expiring leases for crash recovery, and database-backed concurrency controls. Databricks Jobs process PDFs through intelligent document processing and vision/LLM calls, while MLflow Tracing records execution and cost details and dashboard updates combine fast Postgres data with slower billing queries. In production, this architecture avoids external brokers and schedulers while providing durable task management, real-time visibility, and per-task cost attribution.
Supabase Pipelines has moved into public alpha as a service for replicating Supabase Postgres data to external analytical systems in near real time. The release adds automatic application of supported schema changes, faster initial synchronization through parallelism, and a destination request form for ClickHouse, Snowflake, and DuckLake; Google BigQuery is the first destination available to everyone in public alpha. Powered by the open-source Rust-based Supabase ETL, Pipelines uses Postgres logical replication to copy existing tables, stream inserts, updates, deletes, and truncates, and resume from the last acknowledged position after interruptions. It provides at-least-once delivery and managed pipeline controls, while remaining an alpha product with ongoing work on throughput, batching, backpressure, broader schema support, and additional destinations.
Glaspoort replaced a sprawl of outdated, one-off BI reports with a custom application that combines Databricks analytical tools with Lakebase, a serverless Postgres OLTP database. The application keeps curated lakehouse data in a read-only schema while application state occupies a separate schema, and supports development, acceptance, and production environments. Its CI/CD pattern treats database branches like code: long-lived environments branch directly from production, each pull request receives an ephemeral production-shaped branch, migrations are replayed, and a staging app image runs the full test suite against it. This topology makes periodic resets cheap, avoids deleting dependent branches, and preserves fresh test data; the team chose stacked promotion for velocity, retaining a separate crisis pipeline for urgent fixes.
Deploying Eclipse Dataspace Components (EDC) connectors on AWS presents challenges in forecasting infrastructure expenses without clear benchmarks. Estimated costs differ substantially between business-critical setups and non-critical environments based on compute and database sizing. A business-critical configuration relying on Amazon Aurora PostgreSQL db.r6g.large and standard Amazon ECS with AWS Fargate totals an estimated 387.00 USD monthly in the eu-south-2 region. Sizing down to db.t4g.medium and switching to AWS Fargate Spot lowers the non-critical monthly expense to 164.00 USD, representing a 58% reduction. Core cost drivers remain baseline infrastructure components, while storage, API calls, and data transfers contribute marginally under baseline assumptions.
At checkout, fraud scoring must combine transaction inference with customer-specific rules while keeping latency low enough for an interactive payment. The retail-app sample pairs a FastAPI backend and React frontend in a Databricks App with Model Serving route optimization and Lakebase Postgres, where the model retrieves historical features and the backend reads profile controls. A transaction is scored first, then checked against daily spending, international-transaction, and country rules; pooled OAuth-authenticated connections and token-rotation handling avoid repeated handshakes and stale credentials. In the supplied benchmark, route-optimized calls reached 27.2 ms p50 and 37.3 ms p95 end-to-end, with feature lookup at 8.9 ms p50, CatBoost inference at 0.4 ms, and network overhead at 17.4 ms p50; actual performance varies by model.
The best engineering reads, once a week.