title: How default_time_to_live would delete rows without tombstones in Cassandra?
body: <p>From <a href="https://docs.datastax.com/en/cassandra/3.0/cassandra/dml/dmlAboutDeletes.html" rel="noreferrer">How is data deleted?</a></p>
  
  <blockquote>
    <p>Cassandra allows you to set a default_time_to_live property for an entire table. Columns and rows marked with regular TTLs are processed as described above; but when a record exceeds the table-level TTL, <strong>Cassandra deletes it immediately, without tombstoning or compaction</strong>.</p>
  </blockquote>
  
  <p>This is also answered <a href="https://stackoverflow.com/a/50060436/3517383">here</a></p>
  
  <blockquote>
    <p>If a table has default_time_to_live on it then rows that exceed this time limit are <strong>deleted immediately without tombstones being written</strong>. </p>
  </blockquote>
  
  <p>And commented in LastPickle's post <a href="http://thelastpickle.com/blog/2016/07/27/about-deletes-and-tombstones.html#comment-3949581514" rel="noreferrer">About deletes and tombstones</a></p>
  
  <blockquote>
    <p>Another clue to explore would be to use the TTL as a default value if that's a good fit. TTLs set at the table level with 'default_time_to_live' <strong>should not generate any tombstone at all in C*3.0+</strong>. Not tested on my hand, but I read about this.</p>
  </blockquote>
  
  <p>I've made the simplest test that I could imagine using <code>LeveledCompactionStrategy</code>:</p>
  
  <pre><code>CREATE KEYSPACE IF NOT EXISTS temp WITH replication = {'class': 'SimpleStrategy', 'replication_factor': '1'};
  
  CREATE TABLE IF NOT EXISTS temp.test_ttl (
      key text,
      value text,
      PRIMARY KEY (key)
  ) WITH  compaction = { 'class': 'LeveledCompactionStrategy'}
    AND default_time_to_live = 180;
  </code></pre>
  
  <ol>
  <li><code>INSERT INTO temp.test_ttl (key,value) VALUES ('k1','v1');</code></li>
  <li><code>nodetool flush temp</code></li>
  <li><code>sstabledump mc-1-big-Data.db</code>
  <a href="https://i.stack.imgur.com/Lqxqf.png" rel="noreferrer"><img src="https://i.stack.imgur.com/Lqxqf.png" alt="enter image description here"></a></li>
  <li>wait for 180 seconds (default_time_to_live)</li>
  <li><code>sstabledump mc-1-big-Data.db</code>
  <a href="https://i.stack.imgur.com/sLUQU.png" rel="noreferrer"><img src="https://i.stack.imgur.com/sLUQU.png" alt="enter image description here"></a>
  The tombstone isn't created yet</li>
  <li><code>nodetool compact temp</code></li>
  <li><code>sstabledump mc-2-big-Data.db</code>
  <a href="https://i.stack.imgur.com/IGUrN.png" rel="noreferrer"><img src="https://i.stack.imgur.com/IGUrN.png" alt="enter image description here"></a>
  The <strong>tombstone is created</strong> (and not dropped on compaction due to gc_grace_seconds)</li>
  </ol>
  
  <p>The test was performed using apache cassandra 3.0.13</p>
  
  <p>From the example I conclude that isn't true that <code>default_time_to_live</code> not require tombstones, at least for version 3.0.13.
  However this is a very simple test and I'm forcing a major compaction with <code>nodetool compact</code> so I may not be recreating the scenario where default_time_to_live magic comes into play. </p>
  
  <p>But how would C* delete without tombstones? Why this should be a different scenario to using TTL per insert?</p>