Data¶

The Quant Developer Stack in 2026: Self-hosted Market Data, GPU Backtests with Nix and Slurm, and the Path from Notebook to Live Signal

A quant team has two completely different problems to solve. One is research: lots of analysts, lots of notebooks, lots of Parquet, slow human-in-the-loop iteration. The other is production: a small trading desk, kernel-bypass networking, microsecond budgets, almost no humans. The mistake is trying to run both on the same infrastructure. The right answer is two stacks, one boundary.

Stateful ai workloads on kubernetes

Every RAG team hits the same wall six months in. They started with PostgreSQL and pgvector because it was the path of least resistance, the embeddings worked, the retrieval was fine, and nobody had to learn a new system. Then the vector count crossed some invisible threshold — usually around 10M–50M, depending on dimensionality — and recall started sliding, query latency started climbing, and the migration conversation began. The problem: migrating from pgvector to a dedicated vector database while you have live embeddings in production is brutal, and most teams either over-engineer (spinning up a Weaviate cluster for 10K vectors) or under-engineer (running pgvector into the ground at 50M).

This is the decision tree I wish someone had handed me. It's tuned for Kubernetes, June 2026, and every number is from a primary source.

PostgreSQL High Availability with Patroni: 2026 Edition

Running a single PostgreSQL instance in production is a liability. When it goes down — and it will — so does your application. High availability is not optional for production databases; it is the baseline.

This guide builds a production-grade PostgreSQL HA cluster using the fully open-source community stack: PostgreSQL 17 from PGDG, Patroni 4.x, etcd 3.5, pgbackrest 2.58, and HAProxy. No vendor-specific packages. No proprietary repositories. Everything here runs on Rocky Linux 9 or AlmaLinux 9 and stays fully open-source.

PostgreSQL Performance Tuning for Application Developers (2026 Edition)

Slow queries are not a database problem. They are a design problem.

A query that takes 4 seconds on a table with 100 million rows almost always has a fixable root cause: missing index, wrong index type, table bloat, exhausted connection pool, or configuration defaults that were set for a 1GB dataset and never updated. Most performance problems are found — and solved — at the query and schema level before any hardware needs to be touched.

PostgreSQL Server Tuning: The Complete 2026 Configuration Guide

A freshly installed PostgreSQL server is configured to run safely on a shared laptop from 2005. shared_buffers = 128MB. work_mem = 4MB. max_connections = 100. These defaults have not changed in over a decade — and they are deliberately conservative so the server starts without crashing on anything.

Your production server is not a 2005 laptop.

This guide covers every postgresql.conf parameter that matters, the OS-level settings that underpin them, and a ready-to-use configuration reference for common server sizes — all updated for PostgreSQL 17 on Linux in 2026. It is the server configuration companion to the query and index tuning guide, which covers EXPLAIN, indexes, and PgBouncer.