<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Tuning on Меланхоличный блог</title><link>https://notes.melancholic.tech/tags/tuning/</link><description>Recent content in Tuning on Меланхоличный блог</description><generator>Hugo</generator><language>ru-RU</language><lastBuildDate>Sun, 27 Sep 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://notes.melancholic.tech/tags/tuning/index.xml" rel="self" type="application/rss+xml"/><item><title>100 000 записей в секунду на одном PostgreSQL: что реально работает и чем за это платить</title><link>https://notes.melancholic.tech/posts/postgresql-100k-writes-without-sharding/</link><pubDate>Sun, 27 Sep 2026 00:00:00 +0000</pubDate><guid>https://notes.melancholic.tech/posts/postgresql-100k-writes-without-sharding/</guid><description>&lt;p&gt;Когда PostgreSQL упирается в запись, первым рефлексом часто оказывается шардирование: Citus, ручное разбиение в приложении или переезд на NoSQL. Цена у этого решения высокая — распределённые транзакции, сломанные внешние ключи между шардами, миграции схемы на десятках узлов. Подробнее о том, во что обходится шардирование, я писал &lt;a href="https://notes.melancholic.tech/posts/database-sharding/"&gt;отдельно&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;Прежде чем туда идти, стоит выжать один primary. На современном железе и при осознанной настройке он тянет очень много. Ниже — рычаги по порядку убывания отдачи, с поправками к советам, которые кочуют из статьи в статью.&lt;/p&gt;</description></item></channel></rss>