If you use tables like “ReplacingMergeTree” which _explicitly_ states that merges happen in the background, and non-merged rows _will_ be visible.
It’s a table design optimised for specific workloads, and the docs and design detail those tradeoffs.
We use it at work for workloads that can tolerate “retreading” over stale data, because it means they can efficiently write to the db without round tripping, or locking and row updates, and without the table growing massive. It works fantastically in our use case.
It’s a table design optimised for specific workloads, and the docs and design detail those tradeoffs.
We use it at work for workloads that can tolerate “retreading” over stale data, because it means they can efficiently write to the db without round tripping, or locking and row updates, and without the table growing massive. It works fantastically in our use case.