ClickHouse® and Apache Parquet: Past, Present, and Future

Recorded: January 30 @ 07:00 am PST
Presenters: Alexander Zatzev & Doug Tidwell

This webinar is presented by Altinity co-founder and CTO Alexander Zaitsev, with host Doug Tidwell. It covers the complete state of Apache Parquet support in ClickHouse®, from practical read and write patterns through detailed performance benchmarking and compression analysis to the future roadmap.

The session begins with a side-by-side comparison of MergeTree and Parquet. Both are columnar, both use column encodings and compression, and both use column-level metadata to accelerate queries. The structural similarities explain why ClickHouse is well-positioned to work with Parquet efficiently, even though MergeTree is a full database storage engine and Parquet is a standalone file format.

The practical section walks through every common way to interact with Parquet files from ClickHouse: writing a single file using INSERT INTO FUNCTION file(), writing partitioned files using the {_partition_id} macro, reading single and globbed files, reading from and writing to S3, querying public Parquet files via the url() table function, and using the parquet_metadata format to inspect file internals. A hands-on exploration of a public genomics dataset on an HTTP server demonstrates how to parse an HTML page from ClickHouse, extract filenames with regular expressions, create URL-mapped tables in a dedicated database, and use the Merge table function to query all 200 files together. The session also introduces overlay databases as a simpler alternative for S3 and filesystem-backed Parquet collections.

The performance benchmark compares four scenarios using the On Time airline dataset with four representative queries: MergeTree (the baseline), a single Parquet file on local disk, partitioned Parquet files on local disk, and Parquet files on S3. Partitioned local Parquet performs within 2–5x of MergeTree, which is outstanding for a read-only file format. S3 performance was unexpectedly degraded at the time of this recording and was under investigation. Pre-sorting Parquet data to match the MergeTree ORDER BY produced no query improvement because ClickHouse did not yet use that sort information for Parquet.

The compression analysis compares the default On Time MergeTree table (14 GB) against Parquet (4.9 GB) and finds that Parquet achieves nearly 3x better compression. The reason is Parquet’s automatic per-chunk encoding detection. ClickHouse requires a manual codec specification. Using the ALTER TABLE technique to convert low-cardinality string columns to LowCardinality(String), a reduced one column from 500 MB to 49 MB, outperforming Parquet’s 72 MB. Applying LowCardinality to all string columns reduced the overall table size by 30%. Adding ZSTD(1) to all integer columns further reduced size by 2x. The final result still exceeds Parquet’s size, but the gap closes significantly with proper schema design.

The write performance section highlights the output_format_parquet_use_custom_encoder setting, which is off by default as experimental, but delivers 40x faster Parquet writes and is even faster than writing to MergeTree.

The future section covers the ClickHouse 2024 roadmap items for Iceberg catalog support and Hive-style partitioning, enabling the custom encoder by default, ongoing compatibility improvements, and the most ambitious item: Parquet as a native MergeTree part format. This would allow attaching Parquet files directly as MergeTree parts and sharing data between ClickHouse and other Parquet-compatible systems with zero copying.

Here are the slides:

Key Moments (Timestamps)

Key moments generated with AI assistance.

• 00:04 – Welcome and housekeeping
• 01:14 – About Altinity
• 02:00 – ClickHouse overview: architecture and scale
• 03:34 – MergeTree: partitioning, ordering, columnar structure, and key properties
• 07:32 – Apache Parquet: what it is and how it compares to MergeTree
• 09:26 – Writing Parquet files with INSERT INTO FUNCTION file()
• 11:33 – Writing partitioned Parquet files using {_partition_id} macro
• 13:57 – Reading Parquet files: simple queries, glob patterns, and performance preview
• 16:00 – Reading from and writing to S3 with Parquet
• 17:38 – Querying public Parquet files via the URL table function
• 19:04 – Deep dive: querying a genomics dataset from an HTTP server
• 23:57 – Overlay databases: the simpler way to access many Parquet files
• 26:40 – Performance benchmarks: MergeTree vs. single file vs. partitioned vs. S3
• 33:44 – Attempting to sort Parquet data to match MergeTree ORDER BY
• 34:43 – Compression comparison: MergeTree vs. Parquet
• 36:38 – Parquet metadata format for column-level inspection
• 40:10 – Using LowCardinality(String) to close the compression gap
• 44:44 – Write performance: the output_format_parquet_use_custom_encoder setting
• 46:55 – Roadmap: Iceberg catalog, Hive-style partitioning, Parquet as MergeTree format
• 53:47 – Best practices summary
• 54:35 – Q&A: Parquet compatibility with Spark

Webinar Transcript

[00:04] – Welcome and Housekeeping

Doug: Hi everybody, and welcome to another Altinity webinar. I’m your host Doug Tidwell, and we’re very happy to be joined today by Alexander Zaitsev, Altinity co-founder and CTO, and a ClickHouse® expert since 2016. Today’s topic is Apache Parquet, which as you probably know is an open-source column-oriented data file format optimized for speed and efficiency.

A couple of housekeeping notes: this webinar is being recorded so you can watch it again later. I’ll be monitoring the chat for your questions and comments as we go. At the end of the presentation we’ll answer your questions as we have time. So Alexander, the floor is yours.

[01:14] – About Altinity

Alexander: Thank you, Doug. First of all, just in case we have some new people who joined, we are Altinity. We’ve been ClickHouse evangelists for almost eight years. We’ve collected a lot of expertise and contribute to ClickHouse itself and some ecosystem projects. We are the authors of the Altinity Kubernetes Operator for ClickHouse® and we operate ClickHouse on Kubernetes a lot. But today we’ll be talking about something different: how ClickHouse works with Parquet. We’ll discuss the Parquet file format, performance benchmarks, and at the end we’ll talk a little about the future of Parquet in ClickHouse.

[02:00] – ClickHouse Overview

Alexander: Let me remind you a little about ClickHouse itself. ClickHouse is a great database that we all like. It’s SQL, it runs everywhere from Android phones to the cloud and big clusters, thanks to a very universal architecture. That architecture is simple: shared nothing, data stored in columns. Internally it employs a lot of optimizations around vectorized execution and parallelism at all levels, and as such it scales to very big systems. The biggest known ClickHouse installations operate tens or hundreds of petabytes of data. And thanks to the original creators and current maintainers, it’s open source with a very permissive Apache 2.0 license.

[03:34] – MergeTree: The ClickHouse Storage Engine

Alexander: ClickHouse’s main storage format is MergeTree, and it’s important to cover it before going to Parquet, because they resemble each other in several properties.

MergeTree is the special storage engine that defines how data is physically stored on disk. The two main properties are partitioning and ordering. Partitioning in ClickHouse means separate sections of data that never intersect with each other. Quite often partitioning is performed by date or month, but it could be anything. Ordering defines how the data is physically sorted inside the partition. Those two characteristics drive ClickHouse’s famous performance: using partitioning and physical ordering, it’s possible to build very efficient, high-performance query systems.

MergeTree is writable. You can write to it many times. It’s recommended to write in bigger chunks, but you can write single rows and a special background process takes those separately inserted chunks and creates bigger combined chunks to facilitate efficient query processing.

Originally MergeTree was designed as a format for physical storage, so ClickHouse has a lot of optimizations for block devices, including the OS page cache. ClickHouse expects data may live in cache and tries to use it efficiently: for heavy writes it can bypass the cache; for heavy reads that would blow out the cache, it can stream directly to the client.

The four main properties of a MergeTree column: columnar (every column stored as a separate file on the file system), sequential storage in memory and on disk, column encodings to store data more efficiently, and compression. Combined with the physical ordering and sparse index, these properties make queries very efficient.

[07:32] – Apache Parquet: What It Is and How It Compares to MergeTree

Alexander: Now let’s look at Parquet. Parquet is not a database at all. It’s a file format. Originally it was designed for Hadoop and Spark, and as such it’s very widely used in data lakes and can be consumed by many different systems: databases, streaming engines like Apache Kafka, and so on. It’s extensible, open source, part of the Apache Foundation, and being developed and improved continuously.

Parquet has very similar characteristics to MergeTree if you look carefully. It’s also columnar. It also has column encodings similar to MergeTree. It also uses compression. It also uses column metadata to help with query execution, similar to what MergeTree does with its sparse index. So Parquet and MergeTree implement two different things, one a database engine and one a file format, but they are quite similar in structure. That similarity is why we can expect ClickHouse to work very efficiently with Parquet.

[09:26] – Writing Parquet Files with the file() Table Function

Alexander: Let’s start with writing, since we need to prepare data for the tests. I took the On Time dataset, which contains US airline flight data for many years. It’s about 200 million rows: big enough to run meaningful benchmarks, small enough to load quickly. If we take this On Time data stored in a MergeTree table and want to write it to a Parquet file on the local file system, we use a very simple SQL command: INSERT INTO FUNCTION file('ontime.parquet', 'Parquet'). ClickHouse has a feature called table functions, widely used for integration with external systems. File is one example; we’ll also see S3 and URL today. Once we execute this query we can see the file on the local file system in the /var/lib/clickhouse/user_files/ folder, which is roughly 5 GB. The location of this file is configurable; ClickHouse stores files in a special user_files folder by default, but you can change it.

[11:33] – Writing Partitioned Parquet Files

Alexander: A single file is sometimes convenient, but for big datasets it’s not ideal. ClickHouse has a different way to write bigger tables into multiple files using partitioning. To write partitioned Parquet files, you add a PARTITION BY expression to your insert statement and add the {_partition_id} macro inside the file name. For every year in the original table, ClickHouse will create a separate Parquet file using the year value in place of the macro. The result is a separate Parquet file per year, which is convenient to manage and, as we’ll see, very important for performance.

There’s also a SELECT INTO OUTFILE syntax that resembles MySQL. The difference is important: INSERT INTO FUNCTION file() is executed on the server and writes to a server directory, while SELECT INTO OUTFILE is executed on the client and writes to the client filesystem. I personally recommend using INSERT INTO FUNCTION file() to avoid confusion.

[13:57] – Reading Parquet Files: Simple Queries and Globe Patterns

Alexander: Once we have the data in Parquet, let’s start querying it. The simplest query is a count. We get 200 million rows in about 50 milliseconds, which is fast. We can also use glob syntax to query across multiple Parquet files at once, for example file('ontime_*.parquet', 'Parquet') to select all files for all years. We’ll get the same result and it’s actually faster. When we run a more complex query with filtering and grouping and compare single file versus partitioned files, the partitioned version is five times faster. That’s a remarkable difference from a structural choice alone.

[16:00] – Reading from and Writing to S3

Alexander: Similarly to writing and reading local files, we can write and read Parquet from S3. You use the s3() table function and can write with partitioning exactly as before. You can also query S3 buckets the same way. For public buckets there’s a special NOSIGN keyword in recent ClickHouse versions that instructs ClickHouse to make requests without credentials or a signature. For private buckets, ClickHouse supports several authentication approaches: direct credentials in the function call, named collections, IAM role on the ClickHouse VM, or environment variables.

[17:38] – Querying Public Parquet Files via the URL Table Function

Alexander: Let me explore some public Parquet files on the web. I just Googled for public Parquet datasets and found two to demonstrate how you can query some public Parquet data from ClickHouse. One was a Kaggle flights dataset accessible from GitHub. You can query the first row directly. The one setting I had to add was max_http_get_redirects because GitHub makes some redirects to the actual data, and by default ClickHouse doesn’t follow HTTP redirects.

[19:04] – Deep Dive: Querying a Genomics Dataset from an HTTP Server

Alexander: The second dataset is more interesting. It’s a genetics dataset on a public server. The standard download methods provided by the platform are somewhat awkward: FTP, Google Cloud sync, and similar. But I found that there’s actually an HTTP server running, so we can browse the folder and see that there are many Parquet files available. Using DESCRIBE url('http://...file.parquet', 'Parquet') we can see the table structure. This particular dataset has a complex structure with many arrays and tuples, but we can work with it.

To query all 200 files together, we have a few approaches. One approach: generate a batch of INSERT statements, one per file. Another: create a giant UNION ALL table. Neither is convenient.

What I did instead was create a dedicated database in ClickHouse and, for every file, create a separate table using the URL engine. The table name matches the filename exactly, and the engine points to the URL of that particular Parquet file. This creates a mapping of ClickHouse tables to remote Parquet data. Once all those CREATE TABLE statements are executed, we can use SHOW TABLES FROM target_all and see tables named exactly as the Parquet files. Then we can use the Merge table function with a regular expression matching all tables ending in .parquet to query them all together as a single dataset. Virtual columns like _file allow checking row counts per file as a sanity check.

What we accomplished: we took an external dataset placed on a web server, wrote a small ClickHouse query to parse an HTML page, extracted filenames with regular expressions, created a database mapped to those 200 files, and can now run any sort of analysis against them from ClickHouse.

[23:57] – Overlay Databases: The Simpler Way

Alexander: That was pretty inconvenient and required a lot of work. ClickHouse has a simpler way: overlay databases. Unfortunately, overlay databases are not supported for the URL engine, but they are supported for the filesystem, S3, and HDFS engines.

For the filesystem, we create a database using the Filesystem database engine mapped to a folder. All Parquet files in that folder are accessible as tables. If we had an S3 bucket with many Parquet files, we could map a database to that bucket and see all files as tables in that database, without any HTML parsing. ClickHouse automatically understands the Parquet extension and can run queries directly. For S3, this is a neat feature. This is the same outcome as what we did manually with the HTML page, but ClickHouse handles the file discovery automatically.

[26:40] – Performance Benchmarks

Alexander: Let’s talk about performance. For testing I used the On Time dataset and four queries ranging from simple grouping, to filtering on the partition column, to filtering on a non-partition column, to filtering on the MergeTree primary key column. There were four contenders: the original MergeTree table, a single ontime.parquet file, partitioned ontime_*.parquet files, and the same partitioned Parquet data on S3.

Results were interesting. MergeTree (blue bar, smaller is better) is consistently the best: under 100 milliseconds for all queries, reaching 20 milliseconds on the fourth query which uses the primary key. Parquet results varied significantly between single file and partitioned files. The single file was under a second but noticeably slower than ClickHouse. With multiple partitioned files, Parquet performance was only 2–5x slower and in absolute terms was outstanding: around 200 milliseconds. That is very good for a read-only file format.

The S3 results are not shown in this benchmark because S3 Parquet was very slow, taking 2–7 seconds per query. These results are unexpected. Running the same benchmarks a year earlier, S3 Parquet performance was better. Altinity engineers were investigating: a suspected change in ClickHouse’s default parallelism settings or network aggressiveness when fetching from S3.

I also tried sorting the Parquet data the same way as MergeTree (ORDER BY Carrier, FlightDate) to see if ClickHouse could use that ordering for filter acceleration. It did not: the data size was slightly smaller thanks to better locality, but query performance showed no difference. ClickHouse does not yet communicate to the Parquet reader that the data is sorted, so it can’t use it. This is an area for future improvement.

[34:43] – Compression Comparison

Alexander: Both MergeTree and Parquet are known for good compression, but what are the real numbers? The On Time table is not a good compression showcase because it just uses all defaults: no custom codecs, default compression. The result is 3.3x compression for MergeTree. Parquet by default is much smarter. The single Parquet file was 5.3 GB. The partitioned files were even smaller at 4.9 GB because year-level partitioning improves data locality per file. The MergeTree table at 14 GB is three times larger than Parquet’s 4.9 GB.

This is an interesting result, not in favor of ClickHouse. Why? Let’s dig in.

[36:38] – Parquet Metadata: Column-Level Inspection

Alexander: ClickHouse has a special format called parquet_metadata that allows you to read the metadata stored inside a Parquet file. This metadata is huge and in JSON format, describing every column in every row group: physical type, compression, encodings used, and compressed vs. uncompressed sizes.

We can write a query that extracts per-column data from the Parquet metadata and compare compressed sizes between MergeTree and Parquet side by side. Looking at the results: for some columns like elapsed time, arrival delay, and arrival time, Parquet is about 2x more compressed than MergeTree, which is significant. But for two highlighted columns, Parquet is 7x more compressed. Why?

Checking the data in that column, you can see it looks like repeated short strings representing time slots. The number of unique values is not very high, so you’d expect dictionary encoding to help. Parquet applies dictionary encoding automatically. ClickHouse by default stores these as plain strings.

[40:10] – Closing the Compression Gap with LowCardinality

Alexander: The fix in ClickHouse is to convert the column to LowCardinality(String), which is dictionary encoding. This is what Parquet typically applies automatically to most string columns. After altering that one column, it went from 500 MB to 49 MB: an 11x improvement. That is even better than Parquet’s 72 MB for the same column.

What if we modify all string columns to LowCardinality? There are about 100 string columns in this table. We can do it with a neat trick: run a query in the ClickHouse client that generates ALTER TABLE statements for every string column, then pipe the output back to the ClickHouse client to execute them all. After running this, the overall compression improved by 30%, but it’s still much worse than Parquet overall.

Let’s try one more step: apply ZSTD(1) compression to all integer columns. ZSTD(1) is not very compute-intensive and we often recommend it to customers for columns that consume a lot of disk space. Applying it to all integer columns reduced the overall size by another 2x, reaching about 5.8 GB. We’re still slightly behind Parquet’s 4.9 GB, but very close.

The key takeaway: Parquet automatically determines the best encoding and compression per chunk of data, which is more adaptive than ClickHouse’s approach of requiring the user to specify codecs per column globally. With proper schema design using LowCardinality for strings and ZSTD codecs for integers, ClickHouse can match or even beat Parquet’s compression.

[44:44] – Write Performance: The Custom Encoder Setting

Alexander: We haven’t discussed write performance yet. When preparing for this presentation, writing the On Time data to a single Parquet file took over 15 minutes. The performance was around 200,000 rows per second, which is very slow for ClickHouse. Can it be done faster?

Yes. There’s a setting called output_format_parquet_use_custom_encoder. With this setting enabled, writing the same full Parquet file took only 25 seconds, which is 40x faster. On my 32-vCPU test machine, it’s even faster than inserting into a MergeTree table. Why is this setting disabled by default? It’s still classified as experimental, having been added around version 23.7. Expect it to be enabled by default in future versions.

[46:55] – Roadmap: Iceberg Catalog, Hive Partitioning, and Parquet as MergeTree Format

Alexander: ClickHouse published their roadmap for 2024 with two Parquet-related features. First, support for Iceberg data catalogs. Iceberg is a distributed catalog for data lake tables, allowing you to discover and query Parquet files much more easily. If ClickHouse supports it, discovering and querying external Parquet datasets becomes much simpler. Second, Hive-style partitioning support.

The custom encoder enabling by default and compatibility improvements for complex data types and better predicate push-down are also coming. Many of these Parquet compatibility improvements have been contributed by the community rather than just the ClickHouse core team.

The most exciting item on the roadmap is Parquet as a native MergeTree part format. MergeTree on a file system is already a set of files: one per column, plus an index file, plus metadata. There’s even a compact format where all data is stored in a single file, which is very similar to Parquet. What if we made Parquet a supported part format for MergeTree? ClickHouse would write Parquet natively as its storage, and you could take Parquet files and attach them to a MergeTree table as parts directly. This would make ClickHouse data much more portable and interchangeable with other systems: Spark, Python, DuckDB, anything that reads Parquet could access ClickHouse data without conversion. We are very excited about this possibility. If you’re interested in this feature and want it implemented, contact us at Altinity.

[53:47] – Best Practices Summary

Alexander: A few best practices to wrap up.

Always use the latest ClickHouse version for the latest Parquet features, because ClickHouse evolves very rapidly and some results from six months ago are no longer true. Retest and recheck with the latest version. That said, for production use we highly recommend Altinity Stable® Builds for ClickHouse® or LTS releases, which are released on a six-month cadence and offer three years of maintenance.

If you store Parquet data in multiple files, you get much better performance than using a single file. The per-year partitioning in this benchmark yielded a 5x speedup. Use the {_partition_id} macro to control this automatically.

The s3Cluster() function is a great way to work with Parquet and ClickHouse clusters. For a 100-node cluster, it distributes Parquet file reads across all nodes for near-linear scalability. Note that unlike the distributed table engine, s3Cluster() does not rewrite aggregations for the distributed execution model, so the initiator node has to do more final aggregation work.

[54:35] – Q&A: Parquet Compatibility with Spark

Doug: We have a question from Yuri. He says: does ClickHouse write Parquet files with any special non-standard options? He has a situation where a Parquet file written by ClickHouse was not accepted by Spark, possibly a compression codec problem.

Alexander: ClickHouse doesn’t use any special settings as far as I know. There are some knobs you can tune, but I would expect this to be a bug, not a feature, if you couldn’t read it from Spark. Last year we fixed a number of compatibility issues around nullable fields, nullable maps, tuples, and similar edge cases. That could be the reason. It could also be some incompatibility between how ClickHouse interprets certain data types and how other Parquet libraries interpret them. The Parquet standard is actually quite ambiguous for some edge cases, and different Parquet libraries produce different results. If you’re hitting this problem, I’d recommend filing an issue on the ClickHouse repo with a reproducible example, as these compatibility issues get fixed quickly when reported.

Doug: All right, it looks like that answers everyone’s concerns. Thank you so much everyone for being here. We hope this has been useful and we’ll see you again next month with another Altinity webinar.

Alexander: Thank you, Doug.

FAQ Section

Q: What is the fastest way to write Parquet files from ClickHouse?

A: Use the INSERT INTO FUNCTION file('name.parquet', 'Parquet') SELECT ... syntax combined with the output_format_parquet_use_custom_encoder = 1 setting. This setting, available since approximately ClickHouse 23.7, delivers roughly 40x faster Parquet write performance compared to the default encoder and is even faster than writing to a MergeTree table on the same hardware. It is still classified as experimental and is disabled by default, but it is expected to be enabled by default in a future release. For S3, use INSERT INTO FUNCTION s3('s3://bucket/{_partition_id}.parquet', ..., 'Parquet') PARTITION BY expr to write multiple partitioned files in parallel.

Q: How do I query multiple Parquet files at once from ClickHouse?

A: Use the glob syntax in the file() or s3() table function. For example, SELECT ... FROM s3('s3://bucket/ontime_*.parquet', 'Parquet') reads all matching files. Querying multiple smaller partitioned files is consistently faster than querying one large file because ClickHouse can read the files in parallel. A 5x speedup is typical when switching from a single monolithic Parquet file to per-year partitioned files. For larger ClickHouse clusters, the s3Cluster() function distributes file reads across all shards for near-linear performance scaling. For file system or S3 collections, the overlay database feature (e.g., CREATE DATABASE my_db ENGINE = S3('s3://bucket/')) lets you treat all Parquet files in a location as tables without any per-file setup.

Q: Why is ClickHouse’s compression typically worse than Parquet’s by default?

A: Parquet automatically detects the optimal encoding and compression algorithm for every chunk of data independently. For a low-cardinality string column, Parquet automatically applies dictionary encoding; for numerical columns it applies delta or other suitable encodings. ClickHouse requires the user to specify codecs explicitly per column for the entire table. The solution is to use LowCardinality(String) for string columns that have fewer than roughly 10,000 unique values (dictionary encoding equivalent to Parquet’s behavior), and ZSTD(1) for integer columns. After applying these changes to the On Time dataset, the overall table size improved by approximately 60%, narrowing the gap to within 20% of Parquet’s size. The parquet_metadata format can be queried directly to inspect which columns are compressed efficiently in a Parquet file and identify candidates for optimization in the corresponding MergeTree table.

Q: Can ClickHouse use the sort order of a pre-sorted Parquet file to speed up queries?

A: Not at the time of this webinar. Even if you sort a Parquet file with the same column order as a MergeTree ORDER BY, ClickHouse does not yet use that sort information to skip row groups during query execution. Pre-sorting does improve compression slightly due to better data locality, but it provides no query acceleration benefit for Parquet. This is an area identified for future development. MergeTree’s primary key sparse index has no equivalent in ClickHouse’s current Parquet reader.

Q: What is the Parquet metadata format and how can I use it?

A: ClickHouse can read the metadata embedded in a Parquet file using the special parquet_metadata format. For example: SELECT * FROM file('ontime.parquet', 'ParquetMetadata'). The output is a large JSON structure describing every column in every row group: physical type, logical type, compression codec, available encodings, uncompressed size, and compressed size. This is useful for comparing compression ratios per column between ClickHouse and Parquet, identifying columns that benefit from LowCardinality conversion, and understanding what Parquet is doing automatically that you may want to replicate in ClickHouse schema design.

Q: What is the future vision for Parquet in ClickHouse?

A: The most ambitious item on the roadmap is Parquet as a native MergeTree part format. MergeTree already has two internal part formats: wide (one file per column) and compact (all data in one file). Adding Parquet as a third part format would allow ClickHouse to write data natively in Parquet and allow external Parquet files to be attached to MergeTree tables directly as parts with no conversion. This would make ClickHouse data fully portable and interoperable with Spark, Python (PyArrow, PyIceberg), DuckDB, and any other Parquet-compatible system. Other near-term items include Iceberg catalog support, Hive-style partitioning, enabling the custom Parquet encoder by default, Parquet Bloom filter support, and better predicate push-down for queries over S3-backed Parquet collections.

© Altinity, Inc. All rights reserved. Altinity®, Altinity.Cloud®, and Altinity Stable® are registered trademarks of Altinity, Inc. ClickHouse® is a registered trademark of ClickHouse, Inc.; Altinity is not affiliated with or associated with ClickHouse, Inc. Kubernetes, MySQL, and PostgreSQL are trademarks and property of their respective owners.