9 ms·

Haven't used any of these yet, but how does ClickHouse compare to Postgres extensions like TimescaleDB and Citus (which recently launched a columnar feature)? I

Haven't used any of these yet, but how does ClickHouse compare to Postgres extensions like TimescaleDB and Citus (which recently launched a columnar feature)? I remember reading in the ClickHouse docs some time ago that it does not have DELETE functionality. Does this pose any problems with GDPR and data deletion requests?

ryanbooz 5y ago
(Timescale DevRel here) We've recently been working through a detailed benchmark of TimescaleDB and Clickhouse. The DELETE/UPDATE question has been an intriguing story to follow - and I honestly hadn't considered the GDPR angle. ATM, Clickhouse is still OLAP focused and their MergeTree implementation does not allow direct DELETE (or UPDATE) of any data. All DELETE/UPDATE requests are applied asynchronously by (essentially) re-writing/merging the table data (it's referred to as a "mutation") without whatever data was referenced in the DELETE/UPDATE. [1] [1]: https://clickhouse.com/docs/en/sql-reference/statements/alter/#synchronicity-of-alter-queries https://clickhouse.com/docs/en/sql-reference/statements/alte...
- nezirus 5y ago
  You are correct, the proper way to do deletions in ClickHouse is to use partitions, and drop partitions. That is probably good enough for most analytical use cases, but YMMV.
- hkolk 5y ago
  We are using Clickhouse combined with GDPR's Data Deletion Requests. We store the user-ids in a separate system, and run the ALTER/DELETE statements once per week. Works pretty smooth, though I would prefer some more automation within Clickhouse for them. Data for in-active users gets deleted because our clickhouse retention policy is lower than the in-active-user timeout
- kwillets 5y ago
  This question is becoming critical right now, as nonrecoverable deletes are required within 30 days for both GDPR and CCPA. Most products do the asynchronous rewrite, especially if they're based on immutable storage. That's fine, but it should be tested to verify that it's not triggering on every delete, for example, and that it's resource-efficient.
  - ec109685 5y ago
    The other option is to use row level encryption and throw away the keys when a user requests a delete.
- DevKoala 5y ago
  ClickHouse does allow delete and update operations. They are just asynchronous functions. I use them every now and then, but I prefer working with partition strategies when I have to these programmatically.
stingraycharles 5y ago
In a nutshell, my extremely subjective and biased take on it: * Citus has a great clustering story, and a small data warehousing story, afaik no timeseries story; * TimescaleDB has a great timeseries story, and an average data warehousing story; * Clickhouse has a great data warehousing story, an average timeseries story, and a bit meh clustering story (YMMV). (Disclaimer: I work for a competitor)
- akulkarni 5y ago
  [Timescale co-founder] This is a really great comparison. I might borrow it in the future :-) But yes, if you have classic OLAP-style queries (e.g., queries that need to touch every database row), Clickhouse is likely the better option. For anything time-series related, and/or if you like/love Postgres, that is where TimescaleDB shines. (But please make sure you turn on compression!) TimescaleDB also has a good clustering story, which is also improving over time. [0][1] [0] https://news.ycombinator.com/item?id=23272992 https://news.ycombinator.com/item?id=23272992 [1] https://news.ycombinator.com/item?id=24931994 https://news.ycombinator.com/item?id=24931994
  - mromanuk 5y ago
    I like how you always chime in with time series stuff. Just by watching you interact here, boost my confidence on your product
    - akulkarni 5y ago
      Thanks for the kind words. Our first company value is, "Help first." :-)
      - eloff 5y ago
        I can vouch for this. Ajay replies to my emails on a weekend. I'm nobody, not even a customer. He doesn't need to do that at all. I imagine he does it because he's a genuinely good and helpful type of person.
zX41ZdbW 5y ago
There are many independent comparisons of ClickHouse vs TimescaleDB: By Splitbee: https://github.com/ClickHouse/ClickHouse/issues/22398#issuecomment-892207167 https://github.com/ClickHouse/ClickHouse/issues/22398#issuec... By GitLab: https://github.com/ClickHouse/ClickHouse/issues/22398#issuecomment-916969415 https://github.com/ClickHouse/ClickHouse/issues/22398#issuec... And others: https://github.com/ClickHouse/ClickHouse/issues/22398#issuecomment-857275797 https://github.com/ClickHouse/ClickHouse/issues/22398#issuec... https://github.com/ClickHouse/ClickHouse/issues/22398#issuecomment-857276294 https://github.com/ClickHouse/ClickHouse/issues/22398#issuec... If you'll find more, please post it there. TimescaleDB can work pretty fine in time series scenario but does not shine on analytical queries. For most of time series queries, it is below ClickHouse in terms of performance but for small (point) queries it can be better. The main advantage of TimescaleDB is that it better integrates with Postgres (for obvious reasons). There are also many comparisons of ClickHouse vs Citus. The most notable is here: https://blog.cloudflare.com/http-analytics-for-6m-requests-per-second-using-clickhouse/ https://blog.cloudflare.com/http-analytics-for-6m-requests-p... ClickHouse can do batch DELETE operations for data cleanup. https://clickhouse.com/docs/en/sql-reference/statements/alter/delete/ https://clickhouse.com/docs/en/sql-reference/statements/alte... It is not for frequent single-record deletions, but it can fulfill the needs for data cleanup, retention, GDPR requirements. Also you can tune TTL rules in ClickHouse, per table or per columns (say, replace all IP addresses to zero after three months).
- ryanbooz 5y ago
  [Timescale DevRel here] @zX41ZdbW@ - Thanks for pointing out the various benchmarks that have been run by other companies between Clickhouse and TimescaleDB using TSBS[1]. As we mentioned, we'll dig deeper into a similar benchmark with much more detail than any of those examples in an upcoming blog post. One notable omission on all of the benchmarks that we've seen is that none of them enable TimescaleDB compression (which also transforms row-oriented data into a columnar-type format). In our detailed benchmarking, queries on compressed columnar data in Timescale outperformed Clickhouse in most queries, particularly as cardinality increases, often by 5x or more. And with compression of 90% or more, storage is often comparable. (Again, blog post coming soon - we are just making sure our results are accurate before rushing to publish.) The beauty of TimescaleDB columnar compression model is that it allows the user to decide when their workload can benefit from deep/narrow queries of data that doesn't change often (although it can still be modified just like regular row data), verses shallow/wide queries for things like inserting data and near-time queries. It's a hybrid model that provides a lot of flexibility for users AND significantly improves the performance of historical queries. So yes, we do agree that columnar storage is a huge performance win for many types of queries. And of course, with TimescaleDB, one also gets all of the benefits of PostgreSQL and its vibrant ecosystem. Can't wait to share the details in the coming weeks! [1]: https://github.com/timescale/tsbs https://github.com/timescale/tsbs
didip 5y ago
ClickHouse competes with OLAP storages like Druid or Pinot. I don't know about ClickHouse but the other 2 uses bitmap indexes to make storing petabytes of data affordable. Row oriented databases would struggle to compete against ClickHouse. They are easily an order of magnitude slower.
- hodgesrm 5y ago
  ClickHouse uses skip indexes. They basically answer the question "is the value I'm seeking not in the block." For example, there are a couple varieties of Bloom filters, which allow you to test for presence of string sequences in blocks. This allows ClickHouse to skip reading and uncompressing blocks (actually called granules) unnecessarily.
ericb 5y ago
ClickHouse wins on licensing--Apache. The TimeScale licensing approach, the way it is written, perhaps accidentally, has lots of hidden landmines. The TimeScale license slants toward cloud giant defense to the extent that normal use is perilous. For example, timescale can be used for normal data (postgres) as well, so any rules seem to apply to all your data in the database. The free license only usable available if: the customer is prohibited, either contractually or technically, from defining, redefining, or modifying the database schema or other structural aspects of database objects, such as through use of the Timescale Data Definition Interfaces, in a Timescale Database utilized by such Value Added Products or Services. My read is that if you let a customer do anything that adds a custom field, or table, or database, or trigger, or anything that is "structural" (even in the regular relational stuff) anywhere in your database (metrics or not), you are in violation. There doesn't seem to be a distinction about whether this is "direct" control or not, or whether a setting indirectly adds a trigger. I don't want to be in a courtroom debating whether a new metric is a "structural change!" Now, none of that might be the intent of the license, but you have to go by what it says, not intentions. The sad part of that is, I, and I'm sure many folks, have no interest in starting a database company, but we can't rally timescale because of legal risk. Looks awesome otherwise, though.
- akulkarni 5y ago
  [Timescale co-founder here] Hi Eric, thanks for taking a close look at our license. I'd like to dispel some misconceptions: The core of TimescaleDB is Apache2. Advanced features are under the Timescale License. Regarding this: the customer is prohibited, either contractually or technically, from defining, redefining, or modifying the database schema or other structural aspects of database objects, such as through use of the Timescale Data Definition Interfaces, in a Timescale Database utilized by such Value Added Products or Services. My read is that if you let a customer do anything that adds a custom field, or table, or database, or trigger, or anything that is "structural" (even in the regular relational stuff) anywhere in your database (metrics or not), you are in violation. There doesn't seem to be a distinction about whether this is "direct" control or not, or whether a setting indirectly adds a trigger. I don't want to be in a courtroom debating whether a new metric is a "structural change!" That's not correct, and we took pains to clarify that in the license: 3.5 "Timescale Data Definition Interfaces" means SQL commands and other interfaces of the Timescale Software that can be used to define or modify the database schema and other structural aspects of database objects in a Timescale Database, including Data Definition Language (DDL) commands such as CREATE, DROP, ALTER, TRUNCATE, COMMENT, and RENAME. [0] Strictly speaking, if you provide Data Definition Interfaces (DDL) to customers via a SaaS service (ie you are running a TimescaleDBaaS - which applies to < 0.000001% of all possible users) you are in violation of the license. But otherwise you are fine. If you are looking for more votes of confidence, today there are literally millions of active TimescaleDB instances, including by large companies like Walmart, Comcast, IBM, Cisco, Electronic Arts, Bosch, Samsung, and many many smaller ones. [2] If you have any other questions, I'm happy to answer them here, or offline (ajay at timescale dot com). [1] https://www.timescale.com/legal/licenses#section-3-5-timescale-data-definition-interfaces https://www.timescale.com/legal/licenses#section-3-5-timesca... [2] https://www.timescale.com/ https://www.timescale.com/
fiddlerwoaroof 5y ago
I benchmarked ClickHouse vs. Timescale, Citus, Greenplum and Elasticsearch for a real-time analytics application. With a couple hours learning for each (although I’ve used Postgres extensively and so Postgres-backed databases had a bit of an advantage), ClickHouse’s performance was easily an order of magnitude or two better than anything except ES. ES had its own downsides with respect to the queries we could run (which is why we were leaving ES in the first place).
- someguy101010 5y ago
  What did you end up going with?
  - fiddlerwoaroof 5y ago
    ClickHouse deployed to EKS with Clickhouse operator
- eastdakota 5y ago
  Cloudflare’s analytics have been powered by Clickhouse for a long time. And I was an early investor in Timescale. They’re both excellent products.
  - fiddlerwoaroof 5y ago
    Yeah, I was a little disappointed because I was rooting for Timescale myself. And, maybe if I had spent more time optimizing, I could have made Timescale work but, between our experiments and Cloudflare’s blog post about migrating from Citus to ClickHouse, ClickHouse seemed like the one most likely to hold up for our production workloads.
- germandiago 5y ago
  I know of a database that claims to perform even faster than that one, It is commercial, though. For very massive data, in a time-series setup basically. https://www.hydrolix.io/ https://www.hydrolix.io/
deleted 5y ago
[deleted]
lima 5y ago
> I remember reading in the ClickHouse docs some time ago that it does not have DELETE functionality. Does this pose any problems with GDPR and data deletion requests? Clickhouse has ALTER ... DELETE and ALTER ... UPDATE functionality now! (and TTLs)
ddbennett 5y ago
Sentry.io settled on Clickhouse for error and transaction data after reviewing several options including Citus and Elastic. We've been happy with both the performance and how well it scales from Open Source installs to our SaaS clusters.
dagi3d 5y ago
ClickHouse can delete rows but work as batch/async operations: https://clickhouse.com/docs/en/faq/operations/delete-old-data/ https://clickhouse.com/docs/en/faq/operations/delete-old-dat...
- zepearl 5y ago
  Correct + wanted to mention that "lightweight/point-deletes" might come as a new feature. Initial discussion: https://github.com/ClickHouse/ClickHouse/issues/19627 https://github.com/ClickHouse/ClickHouse/issues/19627 Being implemented: https://github.com/ClickHouse/ClickHouse/pull/24755 https://github.com/ClickHouse/ClickHouse/pull/24755
hodgesrm 5y ago
> I remember reading in the ClickHouse docs some time ago that it does not have DELETE functionality. Does this pose any problems with GDPR and data deletion requests? Altinity is fixing this. The project is called Lightweight Delete and it's for exactly the GDPR reason cited. The idea is that there will be a SQL DELETE command that causes rows to disappear instantly. What actually will happen is that they will be marked as deleted, then garbage collected on the next merge. Disclaimer: I work for Altinity.

ryanbooz 5y ago

(Timescale DevRel here) We've recently been working through a detailed benchmark of TimescaleDB and Clickhouse. The DELETE/UPDATE question has been an intriguing story to follow - and I honestly hadn't considered the GDPR angle. ATM, Clickhouse is still OLAP focused and their MergeTree implementation does not allow direct DELETE (or UPDATE) of any data. All DELETE/UPDATE requests are applied asynchronously by (essentially) re-writing/merging the table data (it's referred to as a "mutation") without whatever data was referenced in the DELETE/UPDATE. [1] [1]: https://clickhouse.com/docs/en/sql-reference/statements/alter/#synchronicity-of-alter-queries https://clickhouse.com/docs/en/sql-reference/statements/alte...

nezirus 5y ago
You are correct, the proper way to do deletions in ClickHouse is to use partitions, and drop partitions. That is probably good enough for most analytical use cases, but YMMV.
hkolk 5y ago
We are using Clickhouse combined with GDPR's Data Deletion Requests. We store the user-ids in a separate system, and run the ALTER/DELETE statements once per week. Works pretty smooth, though I would prefer some more automation within Clickhouse for them. Data for in-active users gets deleted because our clickhouse retention policy is lower than the in-active-user timeout
kwillets 5y ago
This question is becoming critical right now, as nonrecoverable deletes are required within 30 days for both GDPR and CCPA. Most products do the asynchronous rewrite, especially if they're based on immutable storage. That's fine, but it should be tested to verify that it's not triggering on every delete, for example, and that it's resource-efficient.
- ec109685 5y ago
  The other option is to use row level encryption and throw away the keys when a user requests a delete.
DevKoala 5y ago
ClickHouse does allow delete and update operations. They are just asynchronous functions. I use them every now and then, but I prefer working with partition strategies when I have to these programmatically.

stingraycharles 5y ago

In a nutshell, my extremely subjective and biased take on it: * Citus has a great clustering story, and a small data warehousing story, afaik no timeseries story; * TimescaleDB has a great timeseries story, and an average data warehousing story; * Clickhouse has a great data warehousing story, an average timeseries story, and a bit meh clustering story (YMMV). (Disclaimer: I work for a competitor)

akulkarni 5y ago
[Timescale co-founder] This is a really great comparison. I might borrow it in the future :-) But yes, if you have classic OLAP-style queries (e.g., queries that need to touch every database row), Clickhouse is likely the better option. For anything time-series related, and/or if you like/love Postgres, that is where TimescaleDB shines. (But please make sure you turn on compression!) TimescaleDB also has a good clustering story, which is also improving over time. [0][1] [0] https://news.ycombinator.com/item?id=23272992 https://news.ycombinator.com/item?id=23272992 [1] https://news.ycombinator.com/item?id=24931994 https://news.ycombinator.com/item?id=24931994
- mromanuk 5y ago
  I like how you always chime in with time series stuff. Just by watching you interact here, boost my confidence on your product
  - akulkarni 5y ago
    Thanks for the kind words. Our first company value is, "Help first." :-)
    - eloff 5y ago
      I can vouch for this. Ajay replies to my emails on a weekend. I'm nobody, not even a customer. He doesn't need to do that at all. I imagine he does it because he's a genuinely good and helpful type of person.

zX41ZdbW 5y ago

There are many independent comparisons of ClickHouse vs TimescaleDB: By Splitbee: https://github.com/ClickHouse/ClickHouse/issues/22398#issuecomment-892207167 https://github.com/ClickHouse/ClickHouse/issues/22398#issuec... By GitLab: https://github.com/ClickHouse/ClickHouse/issues/22398#issuecomment-916969415 https://github.com/ClickHouse/ClickHouse/issues/22398#issuec... And others: https://github.com/ClickHouse/ClickHouse/issues/22398#issuecomment-857275797 https://github.com/ClickHouse/ClickHouse/issues/22398#issuec... https://github.com/ClickHouse/ClickHouse/issues/22398#issuecomment-857276294 https://github.com/ClickHouse/ClickHouse/issues/22398#issuec... If you'll find more, please post it there. TimescaleDB can work pretty fine in time series scenario but does not shine on analytical queries. For most of time series queries, it is below ClickHouse in terms of performance but for small (point) queries it can be better. The main advantage of TimescaleDB is that it better integrates with Postgres (for obvious reasons). There are also many comparisons of ClickHouse vs Citus. The most notable is here: https://blog.cloudflare.com/http-analytics-for-6m-requests-per-second-using-clickhouse/ https://blog.cloudflare.com/http-analytics-for-6m-requests-p... ClickHouse can do batch DELETE operations for data cleanup. https://clickhouse.com/docs/en/sql-reference/statements/alter/delete/ https://clickhouse.com/docs/en/sql-reference/statements/alte... It is not for frequent single-record deletions, but it can fulfill the needs for data cleanup, retention, GDPR requirements. Also you can tune TTL rules in ClickHouse, per table or per columns (say, replace all IP addresses to zero after three months).

ryanbooz 5y ago
[Timescale DevRel here] @zX41ZdbW@ - Thanks for pointing out the various benchmarks that have been run by other companies between Clickhouse and TimescaleDB using TSBS[1]. As we mentioned, we'll dig deeper into a similar benchmark with much more detail than any of those examples in an upcoming blog post. One notable omission on all of the benchmarks that we've seen is that none of them enable TimescaleDB compression (which also transforms row-oriented data into a columnar-type format). In our detailed benchmarking, queries on compressed columnar data in Timescale outperformed Clickhouse in most queries, particularly as cardinality increases, often by 5x or more. And with compression of 90% or more, storage is often comparable. (Again, blog post coming soon - we are just making sure our results are accurate before rushing to publish.) The beauty of TimescaleDB columnar compression model is that it allows the user to decide when their workload can benefit from deep/narrow queries of data that doesn't change often (although it can still be modified just like regular row data), verses shallow/wide queries for things like inserting data and near-time queries. It's a hybrid model that provides a lot of flexibility for users AND significantly improves the performance of historical queries. So yes, we do agree that columnar storage is a huge performance win for many types of queries. And of course, with TimescaleDB, one also gets all of the benefits of PostgreSQL and its vibrant ecosystem. Can't wait to share the details in the coming weeks! [1]: https://github.com/timescale/tsbs https://github.com/timescale/tsbs

didip 5y ago

ClickHouse competes with OLAP storages like Druid or Pinot. I don't know about ClickHouse but the other 2 uses bitmap indexes to make storing petabytes of data affordable. Row oriented databases would struggle to compete against ClickHouse. They are easily an order of magnitude slower.

hodgesrm 5y ago
ClickHouse uses skip indexes. They basically answer the question "is the value I'm seeking not in the block." For example, there are a couple varieties of Bloom filters, which allow you to test for presence of string sequences in blocks. This allows ClickHouse to skip reading and uncompressing blocks (actually called granules) unnecessarily.

ericb 5y ago

ClickHouse wins on licensing--Apache. The TimeScale licensing approach, the way it is written, perhaps accidentally, has lots of hidden landmines. The TimeScale license slants toward cloud giant defense to the extent that normal use is perilous. For example, timescale can be used for normal data (postgres) as well, so any rules seem to apply to all your data in the database. The free license only usable available if: the customer is prohibited, either contractually or technically, from defining, redefining, or modifying the database schema or other structural aspects of database objects, such as through use of the Timescale Data Definition Interfaces, in a Timescale Database utilized by such Value Added Products or Services. My read is that if you let a customer do anything that adds a custom field, or table, or database, or trigger, or anything that is "structural" (even in the regular relational stuff) anywhere in your database (metrics or not), you are in violation. There doesn't seem to be a distinction about whether this is "direct" control or not, or whether a setting indirectly adds a trigger. I don't want to be in a courtroom debating whether a new metric is a "structural change!" Now, none of that might be the intent of the license, but you have to go by what it says, not intentions. The sad part of that is, I, and I'm sure many folks, have no interest in starting a database company, but we can't rally timescale because of legal risk. Looks awesome otherwise, though.

akulkarni 5y ago
[Timescale co-founder here] Hi Eric, thanks for taking a close look at our license. I'd like to dispel some misconceptions: The core of TimescaleDB is Apache2. Advanced features are under the Timescale License. Regarding this: the customer is prohibited, either contractually or technically, from defining, redefining, or modifying the database schema or other structural aspects of database objects, such as through use of the Timescale Data Definition Interfaces, in a Timescale Database utilized by such Value Added Products or Services. My read is that if you let a customer do anything that adds a custom field, or table, or database, or trigger, or anything that is "structural" (even in the regular relational stuff) anywhere in your database (metrics or not), you are in violation. There doesn't seem to be a distinction about whether this is "direct" control or not, or whether a setting indirectly adds a trigger. I don't want to be in a courtroom debating whether a new metric is a "structural change!" That's not correct, and we took pains to clarify that in the license: 3.5 "Timescale Data Definition Interfaces" means SQL commands and other interfaces of the Timescale Software that can be used to define or modify the database schema and other structural aspects of database objects in a Timescale Database, including Data Definition Language (DDL) commands such as CREATE, DROP, ALTER, TRUNCATE, COMMENT, and RENAME. [0] Strictly speaking, if you provide Data Definition Interfaces (DDL) to customers via a SaaS service (ie you are running a TimescaleDBaaS - which applies to < 0.000001% of all possible users) you are in violation of the license. But otherwise you are fine. If you are looking for more votes of confidence, today there are literally millions of active TimescaleDB instances, including by large companies like Walmart, Comcast, IBM, Cisco, Electronic Arts, Bosch, Samsung, and many many smaller ones. [2] If you have any other questions, I'm happy to answer them here, or offline (ajay at timescale dot com). [1] https://www.timescale.com/legal/licenses#section-3-5-timescale-data-definition-interfaces https://www.timescale.com/legal/licenses#section-3-5-timesca... [2] https://www.timescale.com/ https://www.timescale.com/

fiddlerwoaroof 5y ago

I benchmarked ClickHouse vs. Timescale, Citus, Greenplum and Elasticsearch for a real-time analytics application. With a couple hours learning for each (although I’ve used Postgres extensively and so Postgres-backed databases had a bit of an advantage), ClickHouse’s performance was easily an order of magnitude or two better than anything except ES. ES had its own downsides with respect to the queries we could run (which is why we were leaving ES in the first place).

someguy101010 5y ago
What did you end up going with?
- fiddlerwoaroof 5y ago
  ClickHouse deployed to EKS with Clickhouse operator
eastdakota 5y ago
Cloudflare’s analytics have been powered by Clickhouse for a long time. And I was an early investor in Timescale. They’re both excellent products.
- fiddlerwoaroof 5y ago
  Yeah, I was a little disappointed because I was rooting for Timescale myself. And, maybe if I had spent more time optimizing, I could have made Timescale work but, between our experiments and Cloudflare’s blog post about migrating from Citus to ClickHouse, ClickHouse seemed like the one most likely to hold up for our production workloads.
germandiago 5y ago
I know of a database that claims to perform even faster than that one, It is commercial, though. For very massive data, in a time-series setup basically. https://www.hydrolix.io/ https://www.hydrolix.io/

deleted 5y ago

[deleted]

lima 5y ago

> I remember reading in the ClickHouse docs some time ago that it does not have DELETE functionality. Does this pose any problems with GDPR and data deletion requests? Clickhouse has ALTER ... DELETE and ALTER ... UPDATE functionality now! (and TTLs)

ddbennett 5y ago

Sentry.io settled on Clickhouse for error and transaction data after reviewing several options including Citus and Elastic. We've been happy with both the performance and how well it scales from Open Source installs to our SaaS clusters.

dagi3d 5y ago

ClickHouse can delete rows but work as batch/async operations: https://clickhouse.com/docs/en/faq/operations/delete-old-data/ https://clickhouse.com/docs/en/faq/operations/delete-old-dat...

zepearl 5y ago
Correct + wanted to mention that "lightweight/point-deletes" might come as a new feature. Initial discussion: https://github.com/ClickHouse/ClickHouse/issues/19627 https://github.com/ClickHouse/ClickHouse/issues/19627 Being implemented: https://github.com/ClickHouse/ClickHouse/pull/24755 https://github.com/ClickHouse/ClickHouse/pull/24755

hodgesrm 5y ago

> I remember reading in the ClickHouse docs some time ago that it does not have DELETE functionality. Does this pose any problems with GDPR and data deletion requests? Altinity is fixing this. The project is called Lightweight Delete and it's for exactly the GDPR reason cited. The idea is that there will be a SQL DELETE command that causes rows to disappear instantly. What actually will happen is that they will be marked as deleted, then garbage collected on the next merge. Disclaimer: I work for Altinity.