benchANT

Building AI features often means adding a dedicated vector database to the stack. A new system to procure, secure, operate and keep consistent with existing data infrastructure. The question of whether that complexity is always justified is increasingly being raised. PostgreSQL can handle vector workloads through mature open source extensions. In this article, we cover the core concepts, the available extensions with their main characteristics, and what major cloud providers currently support. Read the full article ➡️ https://lnkd.in/eb8-d-qc

Our Co-Founder & CTO Daniel Seybold will be speaking at Berlin Buzzwords 2026 🎙️ June 7-9, in Berlin, he will present: "From OLTP to OLAP: Is #PostgreSQL Eating Analytics Too?" PostgreSQL is now gaining columnar capabilities through extensions like Citus, TigerData columnar, pg_duckdb... which raises a serious architectural question: Can it become a competitive analytics engine? The session will cover: - A structured overview of the PostgreSQL columnar ecosystem - Differences in compression, execution model, and performance - A comparison with established analytical systems like ClickHouse - The structural limits of the approach A technical exploration, no marketing shortcuts. 📍 Berlin Buzzwords 2026 - Kulturbrauerei, Berlin 🇩🇪 🔗 Session details: https://lnkd.in/dAiz5DBb

Is sharding always the next step at scale? OpenAI’s PostgreSQL story suggests the answer is: not necessarily. A few weeks ago, OpenAI shared how they scaled PostgreSQL and the post sparked a huge debate in the community. And for good reason. Scaling to massive usage with one primary instance and dozens of read replicas challenges the idea that sharding is always the obvious path. But the real question is not “sharding or no sharding?” It is 👉 which setup performs best under which workload? That’s where we’d love to see more benchmarks. For example: - PostgreSQL primary + N read replicas - Amazon Aurora-style managed PostgreSQL - Sharded PostgreSQL setups like Azure Cosmos DB for PostgreSQL / Citus How do they compare on reads, writes, latency, failover, operational complexity, and cost? OpenAI’s case is a strong reminder that optimization, replicas, and vertical scaling can buy a lot of time before a major re-architecture. But every workload is different. So here’s the question: which PostgreSQL setups would you like to see benchmarked next? Drop your suggestions in the comments. 👇

PostgreSQL is becoming the de facto standard of the DBaaS market. The data and the strategic moves of the sector's main players all point in the same direction. 3 signals are converging 1️⃣ On the developer side. The Stack Overflow Developer Survey 2025 places PostgreSQL at 55.6% adoption among professional developers, far ahead of MySQL (40.5%). That's +7 points in a single year, the largest jump ever recorded for a database in this survey. It is no longer an open-source outsider, among developers, it is now the default choice. 2️⃣ On the analytical platform side. Snowflake, Databricks and ClickHouse are not adapting to PostgreSQL, they are moving toward its user base. Their goal: capture the analytical workloads of the PostgreSQL world and bring them into their respective ecosystems. They are doing it through acquisitions and partnerships: 👉 Databricks acquired Neon, a serverless PostgreSQL company. 👉 Snowflake acquired Crunchy Data, one of the leading PostgreSQL expert firms. 👉 ClickHouse partnered with Ubicloud, a PostgreSQL DBaaS provider. Each with a different technical approach: Lakebase for Databricks, CDC-based replication for ClickHouse, and Snowflake Postgres for Snowflake. But the same strategic logic: PostgreSQL is where the users are, and the analytical platforms want a piece of that. 3️⃣ On the managed infrastructure side. Managed PostgreSQL is now a standard offering, both at the hyperscalers and at regional Tier 2 providers. Not offering it has become a commercial anomaly. Put together, the three layers of the market (developer adoption, analytics, infrastructure) are converging on the same dialect. Has PostgreSQL already replaced your main production database (or is it next)?

Benchmark results are only as useful as the methodology behind them. If you read benchmarks without checking assumptions, you can draw the wrong architectural conclusions. Here are three common interpretation traps in database benchmarking and how to avoid them.👇 𝗧𝗿𝗮𝗽 #𝟭: 𝗧𝗵𝗿𝗼𝘂𝗴𝗵𝗽𝘂𝘁 𝗶𝘀 𝗻𝗼𝘁 𝘁𝗵𝗲 𝘄𝗵𝗼𝗹𝗲 𝘀𝘁𝗼𝗿𝘆 Average performance metrics hide what actually matters in production: tail latency. A system can look competitive on ops/sec and still deliver a terrible user experience at the 95th percentile. Always check the full latency distribution, not just the headline number. 𝗧𝗿𝗮𝗽 #𝟮: "𝗗𝗲𝗳𝗮𝘂𝗹𝘁" ≠ "𝗳𝗮𝗶𝗿 𝗯𝗮𝘀𝗲𝗹𝗶𝗻𝗲" Comparing a tuned configuration against an untuned one (or vice versa) tells you nothing useful. Methodology disclosure is not optional. It's the whole point. 𝗧𝗿𝗮𝗽 #𝟯: 𝗦𝗰𝗮𝗹𝗶𝗻𝗴 𝗺𝗮𝘁𝗵 𝗱𝗼𝗲𝘀𝗻'𝘁 𝘄𝗼𝗿𝗸 𝘁𝗵𝗲 𝘄𝗮𝘆 𝘆𝗼𝘂 𝘁𝗵𝗶𝗻𝗸 Going from 1 node to 3 nodes does not triple throughput. Replication overhead, coordination cost, and consistency guarantees all eat into that expectation. A modest gain in a distributed setup can still represent a meaningful structural improvement. 𝗪𝗵𝗮𝘁 𝗺𝗮𝗸𝗲𝘀 𝗮 𝗯𝗲𝗻𝗰𝗵𝗺𝗮𝗿𝗸 𝘁𝗿𝘂𝘀𝘁𝘄𝗼𝗿𝘁𝗵𝘆? → Reproducible methodology, publicly documented → Identical infrastructure across all configurations tested → Multiple scaling sizes, not just the favorable one → Vanilla and tuned results, clearly and separately labeled Numbers without context are marketing. Numbers with methodology are evidence.

Apache Cassandra 5 delivers structural performance improvements out of the box. 🚀 But how much more can you extract with basic tuning? In our latest benchmark, we tested Cassandra 5.0.6 vs. the 4.0.0 baseline across 1 to 9 nodes on AWS (YCSB CRUD workload). The results? The default "vanilla" configuration already brings substantial gains. However, applying conservative, best-practice tuning unlocks a whole new level of performance. On our 9-node XLARGE cluster, a tuned setup pushes throughput past 171,500 ops/sec, a +23% improvement over Cassandra 4. Now it’s your turn! 👉 Submit your own Cassandra tuning for the YCSB CRUD workload, and we'll publish the results alongside ours in the BenchANT ranking. Same cluster. Same workload. Fair comparison.

OLTP, OLAP, HTAP, NoSQL, Time-Series: each domain has its own benchmarking tools. Some are well-established. Others have just emerged to address architectures that classic suites never covered. Distributed SQL systems need benchmarks that account for coordination overhead. Hybrid transactional/analytical workloads demand tools that measure workload interference and data freshness. Real-time ingestion patterns require evaluation of concurrent ingest and query performance. Globally distributed NoSQL deployments call for cross-region latency and replication-aware testing. Classic benchmark suites weren't built for this. New ones are. We published a structured update to our benchmark suite compendium, covering new frameworks that became relevant in 2026: → OLTP: pgdistbench, Swingbench → OLAP: analytics_benchmark, RTABench, SQLStorm, Benchto, Firebolt Benchmarks, RedBench → HTAP: Web3Bench, HyBench-2024 → NoSQL: Tectonic, Global NoSQL Benchmark, Latte, OpenSearch Benchmark → Time-Series: nano For each suite: origin, technical scope, workload characteristics, and real-world use cases. Like of the article in the comment.

New major release, promised gains in throughput, latency, and concurrency handling… But what happens when tested under fully reproducible, controlled conditions? We put Cassandra 5 through the same YCSB protocol as Cassandra 4: identical infrastructure, identical workload, across five cluster sizes. Explore the full open database ranking and see how Cassandra 5 stacks up. Read the full article 👉 https://lnkd.in/daH4AyPp

New major release, promised gains in throughput, latency, and concurrency handling… But what happens when tested under fully reproducible, controlled conditions? We put Cassandra 5 through the same YCSB protocol as Cassandra 4: identical infrastructure, identical workload, across five cluster sizes. Explore the full open database ranking and see how Cassandra 5 stacks up. Read the full article 👉 https://lnkd.in/daH4AyPp

Workload first. Benchmark second! The exact same database can score completely differently depending on the workload type being tested. Without first defining whether your system handles transactions, analytics, or a sustained mixed load, any benchmark result is meaningless. Understanding the difference between OLTP, OLAP, and HTAP is the foundation of any reliable, data-driven IT decision. ➡️ Swipe through the carousel to see how these three workloads differ and how we evaluate them.