# Lots of small inserts cause a growing WAL. How to handle this? **URL:** \ **Category:** Community\ **Tags:** config, question\ **Created:** [February 18, 2026, 11:43am UTC](https://community.questdb.com/t/lots-of-small-inserts-cause-a-growing-wal-how-to-handle-this/960 "2026-02-18T11:43:54Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![YBrink](https://avatars.discourse-cdn.com/v4/letter/y/f19dbf/32.png) [@YBrink](https://community.questdb.com/u/YBrink)\ **Post date:** [February 18, 2026, 11:43am UTC](https://community.questdb.com/t/lots-of-small-inserts-cause-a-growing-wal-how-to-handle-this/960/1 "2026-02-18T11:43:54Z")
### **Old situation** Originally, we were operating on a relational database, with our data grouped by value type\*\*.\*\* All data points from all sources of matching value types were mixed together inside these type‑based tables. All our data is timestamped, and we mainly access it by timestamp, so for performance, we thought we’d switch to questdb. **New situation** Our default ttl is 93 days, so if a data source starts writing a lot to a grouped table, even if we switch to a separate table with smaller ttl, that other data will be retained for 93 days. So we split the tables into a table per data source, to make use of TTL properly. Because of that split, we’re now inserting a few records in lots of tables. We use the QuestDB sender with flush threshold: 50,000 rows and flush interval: 1 second. Despite low per‑table ingestion rates, the WAL apply process cannot keep up. `wal_pending_row_count` keeps climbing on many tables, while the CPU stays around 30%. So, the issue seems to lie in having lots of tables with small writes rather than large batches. But squishing tables back together again wouldn’t work either in case of conflicting TTL. What is the best solution here? Is it possible to speed up the writing of WAL to table? Or should we simply attempt to reduce our table count as much as possible? ---
**Author:** ![nwoolmer](https://yyz2.discourse-cdn.com/flex004/user_avatar/community.questdb.com/nwoolmer/32/24_2.png) [@nwoolmer](https://community.questdb.com/u/nwoolmer)\ **Post date:** [February 18, 2026, 11:49am UTC](https://community.questdb.com/t/lots-of-small-inserts-cause-a-growing-wal-how-to-handle-this/960/2 "2026-02-18T11:49:07Z")
Hi @YBrink , how many tables, and what hardware are you using? With this kind of setup, you probably need to reduce `cairo.writer.data.append.page.size` and increase `wal.apply.worker.count`. It’s also important to use a fast disk and filesystem, and avoid uising `sync` mode. By default, the database uses `nosync` mode, which allows the OS to `fsync` data at will. This trades durability for performance, so ensure you take frequent snapshots. Ideally, you would have fewer tables, so perhaps you can explain a bit more about your data and schema, and we can find a good middle ground. ---
**Author:** ![YBrink](https://avatars.discourse-cdn.com/v4/letter/y/f19dbf/32.png) [@YBrink](https://community.questdb.com/u/YBrink)\ **Post date:** [February 18, 2026, 4:11pm UTC](https://community.questdb.com/t/lots-of-small-inserts-cause-a-growing-wal-how-to-handle-this/960/3 "2026-02-18T16:11:22Z")
Hi @nwoolmer About 600 tables (this is our worst case scenario). Our cpu has 4 cores and hyperthreading (Intel I5), the disk questdb is on is an ssd. Outside of `cairo.writer.data.append.page.size` and `wal.apply.worker.count` we haven’t touched the settings, so nosync is on. Data-wise, we write about 10-30 records every 2 milliseconds, each of which comes from a different datasource. (on more robust systems we’d want that number higher). The current schema is very simple: a timestamp and a value. We’d prefer having more separate tables, but if needed we can squash things down to 7 or 8 tables per value type (for differing ttls) resulting in about 35-40ish tables. ---
**Author:** ![nwoolmer](https://yyz2.discourse-cdn.com/flex004/user_avatar/community.questdb.com/nwoolmer/32/24_2.png) [@nwoolmer](https://community.questdb.com/u/nwoolmer)\ **Post date:** [February 18, 2026, 4:13pm UTC](https://community.questdb.com/t/lots-of-small-inserts-cause-a-growing-wal-how-to-handle-this/960/4 "2026-02-18T16:13:21Z")
A 500 Hz txn rate is quite high, are you able to reduce this to perhaps 10 Hz, which should give you a better batch size? Since you only have single values, you might benefit from using a narrow schema for this kind of ingestion i.e. `timestamp, sensor, value`, which would allow you to write larger batches to fewer tables. You can re-arrange this data after the fact, copy it to different tables, build materialised views etc. ---
**Author:** ![YBrink](https://avatars.discourse-cdn.com/v4/letter/y/f19dbf/32.png) [@YBrink](https://community.questdb.com/u/YBrink)\ **Post date:** [February 19, 2026, 1:34pm UTC](https://community.questdb.com/t/lots-of-small-inserts-cause-a-growing-wal-how-to-handle-this/960/5 "2026-02-19T13:34:04Z")
Sorry, to be clear, the write to questDB occurs on every flush at either 50000 records or the 1 second default. We put new records into the sender every 2 milliseconds, but we don’t flush at that time. We’re going to apply the schema as you proposed and see if that has effect. Thanks for the help so far! ---
**Author:** ![YBrink](https://avatars.discourse-cdn.com/v4/letter/y/f19dbf/32.png) [@YBrink](https://community.questdb.com/u/YBrink)\ **Post date:** [February 19, 2026, 1:34pm UTC](https://community.questdb.com/t/lots-of-small-inserts-cause-a-growing-wal-how-to-handle-this/960/6 "2026-02-19T13:34:09Z")
We’ve reduced the amount of tables to at most 20, with currently four in use. As of yet, the waltables() are looking like this for those four: ![image](https://canada1.discourse-cdn.com/flex004/uploads/questdb/original/1X/8fee8e6f6f707cef501aebaefef6bc85627a93ff.png) Text table will slowly tick up, float table rapidly, and the other tables at an intermediate pace. Assuming this, with the schema of `timestamp, value, symbol, symbol` for each of these, what settings should I fiddle with now? I take it the page append size can return back to the default setting? ---
**Author:** ![nwoolmer](https://yyz2.discourse-cdn.com/flex004/user_avatar/community.questdb.com/nwoolmer/32/24_2.png) [@nwoolmer](https://community.questdb.com/u/nwoolmer)\ **Post date:** [February 19, 2026, 1:36pm UTC](https://community.questdb.com/t/lots-of-small-inserts-cause-a-growing-wal-how-to-handle-this/960/7 "2026-02-19T13:36:24Z")
Please can you share the built-in ingestion metrics charts for the tables? They are located next to the refresh button at the top of the tables window. ![image](https://canada1.discourse-cdn.com/flex004/uploads/questdb/original/1X/afd63499ee3ea41defb26e3fa52458cbd14734a0.png) There are 5 widgets, all are important. Additionally, if you are using newer versions of QuestDB, `tables()` has additional summary metrics for ingestion. It’d be great if you could run that and then hit the ‘copy as markdown’ button: ![image](https://canada1.discourse-cdn.com/flex004/uploads/questdb/original/1X/19821d45438135eb4477ba59402cc5c6faf119f3.png) ---
**Author:** ![YBrink](https://avatars.discourse-cdn.com/v4/letter/y/f19dbf/32.png) [@YBrink](https://community.questdb.com/u/YBrink)\ **Post date:** [February 19, 2026, 4:35pm UTC](https://community.questdb.com/t/lots-of-small-inserts-cause-a-growing-wal-how-to-handle-this/960/8 "2026-02-19T16:35:08Z")
So, part of the problem was that, despite having dropped the old 600 or so tables (and them no longer showing in questdb), the log showed the server was still busy handling that deletion. Specifically: `i.q.c.w.WalPurgeJob table is not fully dropped, pinging WAL Apply job to delete table files` After deleting those files manually (multiple gigabytes worth of data), everything started working smoothly! Thanks for al the help 🙂 (The other part of the problem was having that many tables in the first place, we pared it down to 20) ---
**Author:** ![nwoolmer](https://yyz2.discourse-cdn.com/flex004/user_avatar/community.questdb.com/nwoolmer/32/24_2.png) [@nwoolmer](https://community.questdb.com/u/nwoolmer)\ **Post date:** [February 19, 2026, 4:37pm UTC](https://community.questdb.com/t/lots-of-small-inserts-cause-a-growing-wal-how-to-handle-this/960/9 "2026-02-19T16:37:03Z")
Ah yes indeed, if you have very backed up tables, it can take a while to clean them up on drop. In future, you should be able to short circuit this by truncating them first or converting them to non-WAL. We have been working on speeding this up but it will be version dependent: [chore(core): release disk space faster on table drop by ideoma · Pull Request #6585 · questdb/questdb · GitHub](https://github.com/questdb/questdb/pull/6585) Do reach out if you have any more trouble!